It should be a goal to keep all of OpenBIOS/Paflof independent from a certain compiler, though this might show up as an effort that is not paying out in the end.
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.
Will we get the specs of harware for GPL implementation of drivers at all, when we don't even have a gcc on that platform? On the other hand, writing plain and clean C without bells and whistles is kind of a design manifestum to claim being a portable implementation. Gcc produces ugly code on many non x86 platforms, and it's pretty buggy. On some 64bit platforms, current stable gcc does not even compile the patches I sent earlier today.
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.
Relying on 64bit, you have some simple rules on all GNU systems (that I know of right now): sizeof(long)==sizeof(pointer_t) and sizeof(int)==4. These wrenches are (Segher, is this right?) only to do double cell arithmetics without having to code them down by hand (which would bloat the code instead of letting the compiler do a nice job with using the CPUs features to do this task atomically)
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.
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 ;)
As for the Gnu-isms, we wrap the necessary code in #ifdef __GNUC__, in some cases creating a null macro to reduce the subsequent ifdef mess:
#ifndef __GNU_C__ #define __attribute__(arg) /* noop */ #endifIt might be a viable way to have one abstract set of lowest level functions for each c compiler, i.e. a ccdep-gcc.c with all the defines, pointer sizes etc, which are abstracted from the rest of the code.
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.
Then again - we will look into portability and improve certain parts of code, as soon as there is something working at all. Due to the nice way of partitioning functionality in open firmware and forth, it should be easy to improve certain parts of the cellar, even if the roof is already built and water proof.
Very true. In fact, I'm going to change the dictionary layout today :)
Segher
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..