[OpenBIOS] 64bit paflof with lots of gnuisms

[Segher Boessenkool]

> 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 */
> >     #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.

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 at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..