[OpenBIOS] 64bit paflof with lots of gnuisms
stepan at suse.de
Tue Jun 4 17:53:35 CEST 2002
* Segher Boessenkool <segher at 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
> 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.
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
To unsubscribe: send mail to majordomo at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..
More information about the openbios