[OpenBIOS] 64bit paflof with lots of gnuisms

[Stefan Reinauer]

> >+#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

-- 
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..