In message 20020603181539.GB19105@suse.de, Stefan Reinauer writes:
typedef intptr_t type_n; // cell size typedef uintptr_t type_u; // cell size +#if defined(__alpha__) || defined(__x86_64__) || \
- defined(__ia64__) || defined(ppc64)
+typedef intmax_t type_d __attribute__ ((mode (TI))); // 2 * cell size +typedef uintmax_t type_du __attribute__ ((mode (TI))); // 2 * cell size +#else typedef intmax_t type_d; // 2 * cell size typedef uintmax_t type_du; // 2 * cell size +#endif #else
Dunno about the Gnu-isms, 'cause we avoid 'em in SmartFirmware, but as a general rule, you should change your defines to something like this:
typedef intptr_t type_n; // cell size typedef uintptr_t type_u; // cell size +#ifdef int64_type +typedef intmax_t type_d __attribute__ ((mode (TI))); // 2 * cell size +typedef uintmax_t type_du __attribute__ ((mode (TI))); // 2 * cell size +#else typedef intmax_t type_d; // 2 * cell size typedef uintmax_t type_du; // 2 * cell size +#endif #else
and have a machine-dependent section that sets int64_type (or whatever) based on the CPU type or some-such. Make the macros reflect the specific feature directly.
We use two different macros defined in a machdep.h header file, which is customized for each platform and compiler. One macro determines the presence/absence of 64-bit ints (say INT_64BIT) and another determines if pointers will be 64-bits or not (PTR_64BIT). Only one place needs to specify the settings of these macros, machdep.h, and every other common source file is neatly disconnected from any machine dependancies.
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 */ #endif
Obviously, there are other ways to deal with this as well.
Just for what it's worth.
-- Parag - 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..
+#if defined(__alpha__) || defined(__x86_64__) || \
- defined(__ia64__) || defined(ppc64)
Dunno about the Gnu-isms, 'cause we avoid 'em in SmartFirmware, but as a general rule, you should change your defines to something like this:
+#ifdef int64_type
and have a machine-dependent section that sets int64_type (or whatever) based on the CPU type or some-such. Make the macros reflect the specific feature directly.
agreed. Actually I was looking for a more sane way to detect whether there is a 128bit value for double cell operations that safes working those out in code. This might be interesting to use certain cpu instructions made for cell size multiplication and such (Even though I guess it just makes the code look nice, but I have no real life benchmarks to determine whether this is microoptimization or not.) IIRC, Alpha and Itanium support this kind of operation in hardware, probably the hammer does as well.
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. 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.
We use two different macros defined in a machdep.h header file, which is customized for each platform and compiler. One macro determines the presence/absence of 64-bit ints (say INT_64BIT) and another determines if pointers will be 64-bits or not (PTR_64BIT). Only one place needs to specify the settings of these macros, machdep.h, and every other common source file is neatly disconnected from any machine dependancies.
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)
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 */ #endif
It 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. 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.
Stefan
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..
* 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
On Tue, 4 Jun 2002, Stefan Reinauer wrote:
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
FYI, for MIPS platforms you can select between 32-bit and 64-bit ints with a compiler option. It probably only makes sense for MIPS64*/Linux if at all, and 64-bit ints are non-default and detectable with the _MIPS_SZINT macro.
Anyway, <stdint.h> is probably the right header to get types of fixed sizes. Unfortunately, it's part of glibc rather than gcc, for a reason unknown to me, at least with gcc 2.95.
-
Maciej W. Rozycki -
Parag Patel -
Segher Boessenkool -
Stefan Reinauer