* Segher Boessenkool segher@chello.nl [020604 14:22]:
Minimum requirement is a C99 compiler that supports &&label. That's only gcc, i guess.
It's not feasible to write a inner interpreter in portable C; it'd be way too slow.
same thing probably applies for double cell arithmetic, which can be in hardware on most platforms, but is not necessarily supported by non-gcc compilers, at least for 64bit platforms.
gcc-3.0.4 for alpha crashes on compiling any version of paflof.
I'm not going to require gcc-3.1 right now, so we'll have to live with the lowest common denominator right now, that is, gcc-2.95. Unfortunately, 2.95's libgcc does not have support routines for TImode, so that trick won't work. Also, printf("%zd", sizeof(bla)) doesn't work in 2.95.
gcc 3.0.4 should not be used for any production level linux systems. I consider it an interim release which will hopefully go away from all systems soon. Anything newer than 2.95.x should require 3.1 _at least_. On iirc all platforms except x86 gcc 2.95.x is not really usable at all (alpha, itanium, hammer, ppc come to my mind) Paflof works fine alpha when using gcc 3.1.x, currently I only know about some ICE on x86-64, which should be solved before the machines are available.
A cell is an integer the size of a pointer; that's a "long" in gcc. I don't think sizeof(int) == 4 always holds.
Theoretically could there be an architecture, where an int is bigger than a pointer (cray?), but if we don't support those, nobody will bite us, i bet. SuperH has 32bit chars. Would be nice to have some game consoles supported by OpenBIOS somewhen ;) but this is neither an issue nor should it hurt due to the IEEE standard
Paflof only needs bigger-than-long integers to handle double cell arithmetic, and at the moment it doesn't really matter if i fake it (i.e., pretend a "long long" is always twice as long as a "long").
The most important reason for not doing the double cell arithmetic support stuff ourselves, is that libgcc already contains those. That is, unless you are unlucky enough to have gcc-2.95 ;)
We only need to use TI mode on 64bit platforms, but those are not usable with gcc 2.95.x, so with a couple of ifdefs this should not hurt getting things work with 2.95.x on x86, and use 3.1 where it is needed. Within the next year gcc 2.95 will vanish anyways and before we have a wide range of hardware supported by OpenBIOS it will definitely be gone. I see that there might be a lot of interest for OpenBIOS on those Alphas that have to use milo at the moment, which is an ugly pile of code. The sooner it is replaced by something sane the better. For those few that have a 64bit machine, but no gcc 3.1 we will find some solution. As soon as paflof is about complete, changes will mainly be in the forth layer above it anyways.
The inner interpreter is a big loop that jumps to computed labels. If other compilers than gcc support this, we might think about supporting them; but Paflof is meant as a portable Open Firmware for Linux, and if you have Linux, you have GCC, so there's not much point in trying to support other compilers, i think.
As this whole issue is gcc specific, not Linux specific, any OS can be used for development. Nobody has an excuse not to contribute this way ;) If you are going to pariticipate and flash a completely new firmware, installing gcc is not a too high barrier.
Very true. In fact, I'm going to change the dictionary layout today :)
Can you please include the TI mode stuff #ifdef'ed For __alpha__, __ppc64__, __x86_64__ and __ia64__ - Afaik none of them except Alpha has gcc 2.95 available anyways. And if they do, I would never even think about flashing something to firmware on those platforms if it was compiled with 2.95.
Stefan