New test to show memory model of platform newLISP is compili

[TedWalther]

Here is a test that could be incorporated into the configure script of newLISP to automaticaly decide whether to use the -DNEWLISP64 define.



Maybe I should just make the patch.   But here is the code.



Would it be fair to say that we ONLY support the LP64 and the ILP32 memory models?

Code Select Expand


#include <stdio>

int
main(int argc, char** argv) {
short sc = sizeof(char) * 8;
short ss = sizeof(short) * 8;
short si = sizeof(int) * 8;
short sl = sizeof(long) * 8;
short sp = sizeof(void*) * 8;

if (si == 32 && sl == 64 && sp == 64) { printf("LP64n"); return 0; }
if (si == 64 && sl == 64 && sp == 64) { printf("ILP64n"); return 0; }
if (si == 32 && sl == 32 && sp == 64) { printf("LLP64n"); return 0; }
if (si == 32 && sl == 32 && sp == 32) { printf("ILP32n"); return 0; }
if (si == 16 && sl == 32 && sp == 32) { printf("LP32n"); return 0; }
}


[Lutz]

Yes, only LP64 and ILP32 are supported out of the box in newLISP and they are kind of the current standard. Unfortunately other models are around in older OSs, e.g. TRU64, but people have successfully tweeked newLISP to compile/link/run with those too.



Note that for LP64 versus ILP32 only the sizes of 'long' and 'void *' matter all others are the same for both models. LP64 was specifically defined to be easy to port too from widely used ILP32 keeping 'char', 'short', 'int', 'float' and 'double' the same size.



A program newlisp-x.x.x/util/types.c can also be found generating a report for any platform displaying type sizes and formatting characters for numbers and the endianess of the CPU.



run it 3 times, and see what happes

Code Select Expand

gcc type.c -o types
gcc -m32 type.c -o types
gcc -m64 type.c -o types


The first tells you the default and the others if libc is present for that memory model.



I am reluctant to make the choice for 64 versus 32 bit automatic, as many platforms offer both, and the choice for one or th other depends on the type of applications to be run, available memory, libraries etc..

[TedWalther]

Ok, I'll update my patch to have an automatic determination, but then let a configure option override it.



Can you tell me more about the platforms that are neither LP64 or ILP32? I'd like to account for and incorporate them in the re-vamped configuration system.



Also, sorry the patch is offline, my servers are all down due to a faulty switch.  I can make it available elsewhere.



Ted

[Lutz]

Ok, I'll update my patch to have an automatic determination, but then let a configure option override it.

that sounds like a good solution!



http://reactor-core.org">http://reactor-core.org still seems to be down, so I haven't been able to try it yet.

[TedWalther]

Ok, changes are done.  Here is what the patch currently does:



* Changes TRUE64 to TRU64 in a couple places for consistency.

* Puts in a msising semicolon in nl-sock.c so the IPv6 code compiles again (syntax error)

* adds a "distclean" target to the main Makefile to remove files generated by configure and the newlisp binary itself.  This is standard GNU/Debian practice.

* added --help option to configure explaining the different available options

* Updates configure file to generate a makefile based on the current system

* Automatically detects the memory model

* Sets NEWLISP64 if the memory model is LP64

* Sets MEMORY_MODEL_XXX based on the actual memory model, whether it is ILP32, LP32, LLP64, LP64, or ILP64.   And if it isn't any of these, it sets UNKNOWN.

* Adds options to configure to explicitly set the memory model to any of the above five known memory models, which completely overrides the auto-detected value, even in the MEMORY_MODEL_XXX define.

* Adds options to configure to enable or disable IPv6, readline, and utf8 on an individual basis

* renamed test program test-lp64 to test-memorymodel, because it now supports all five known memory models



When debugging, if the script doesn't work, please email me the config.h and makefile_configure, also the result of "uname -a" and "dmesg" commands if you could.



Lutz, you will find the patch on M4 in the main directory.  I await further feedback.  If you could forward it on to the AIX and TRU64 guys, I'd appreciate their feedback too.  Apart from the Makefiles, I'd like to know what tweaks they had to make.  If it was just Makefiles, then right on, I can quickly incorporate that into the system.

[TedWalther]

The patch is called newlisp-configure.patch

[Ryon]

Where is this patch located? I've tried http://reactor-core.org">http://reactor-core.org and don't see any reference. I'm having trouble installing on this Debian server.



UPDATE: Oh! There it is, in the previous thread. Though I'm even more confused now. Do I run this as a script in /newlisp-10.1.0 ? I tried, and got a long list of errors.



BTW, that reactor-core.org, and Ted Walther's blog are excellent! I'm going to be doing a LOT of reading!