[parisc-linux] Some PA-RISC 2.0 Gotchas

[parisc-linux] Some PA-RISC 2.0 Gotchas

[John Curry]

Hello all,
            we have been looking into the kernel code for porting to the 2.0
Architecture. We have
stumbled upon a few gothas:

- In 2.0, function pointers are not addresses to functions, but are
addresses to data strcutures
called "function descriptors". So, if assembly code gets passed a pointer to
a function, it will have
to remember which slot in the "function descriptor" the actual function
pointer resides.

- There are some places in the kernel where the implicit assumption that
longs == ints will break!
For example, the parisc_set_bit  function is used in several places to
operate on bitmaps of type long.
Obviously, this function (and the other related functions) has to converted
to operate on 64-bit quantities.
But, in the free_area_struc type, the map variable is declared as an integer
ptr. Depending on the size of
the bitmap, this will cause the parisc_set_bit  to operate incorrectly. We
solved this problem by making
the map variable a unsigned long pointer.

- The 32-bit assembly LDIL, LDO trick of getting the address of some label
(or address) will not work the way you want.
In the 64-bit architeture, you will have to use MFIA in conjunction with
loading the difference from the address
you want, to where you are.


Hope these are of some use.

J.C.

Re: [parisc-linux] Some PA-RISC 2.0 Gotchas

[Stan Sieler]

Re: 

> - In 2.0, function pointers are not addresses to functions, but are
> addresses to data strcutures
> called "function descriptors". So, if assembly code gets passed a pointer to
> a function, it will have
> to remember which slot in the "function descriptor" the actual function
> pointer resides.

They're pointers to data on HP-UX 10.20 as well.
 
> - There are some places in the kernel where the implicit assumption that
> longs == ints will break!

:)

My pet peeve...

Code should almost *never* use "short", "int", or "long" ... 
but instead, "int32" and "int64" (or whatever) should be used.  

I've lost track of the number of bugs I've seen caused by this.  
(Ok, one exception...if you're calling a system function documented as 
using "int" or "long", then you can declare variables of those type 
... but be very careful using them, and file a bug report with the vendor :)

-- 
Stan Sieler                                           sieler@allegro.com
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

Re: [parisc-linux] Some PA-RISC 2.0 Gotchas

[Philipp Rumpf]

> But, in the free_area_struc type, the map variable is declared as an integer
> ptr. Depending on the size of
> the bitmap, this will cause the parisc_set_bit  to operate incorrectly. We
> solved this problem by making
> the map variable a unsigned long pointer.

it's very unlikely map isn't a multiple of 8 bytes, but I agree this type
should be changed.

> Hope these are of some use.

Thanks, I'm sure they will.

	Philipp

Re: [parisc-linux] Some PA-RISC 2.0 Gotchas

[Christopher Neufeld]

On Feb 11,  9:52am, Stan Sieler wrote:
> 
>> - There are some places in the kernel where the implicit assumption that
>> longs == ints will break!
>
>My pet peeve...
>
>Code should almost *never* use "short", "int", or "long" ... 
>but instead, "int32" and "int64" (or whatever) should be used.  
>
   The types are "int32_t", "int64_t", etc. These are codified in the C99
standard which was finally ratified late last year. The previous
standard, C89, did not define these types, and so portable code could not
use them, short of a person rewriting the typedefs in the program's
header files for each new architecture/compiler.

   There are many circumstances where one wants to use those particular
K&R types. "int", for example, is intended to be implemented in the
machine's natural word size. While not required by the standard, the
recommendation allows you to expect that code using ints will probably be
at least as quick as code using other integer types (neglecting "real
world" impacts like memory bandwidth and cache size). If you look in a
C99-compliant <stdint.h> header file you'll see that there are types like
"int_fast16_t" which are mapped not to an integer of size 16, but to an
integer of the natural word size of the machine (on x86 that means that
int_fast16_t and int_fast32_t are both typedef-ed to int, and on a 64 bit
architecture int_fast16_t is typedef-ed to a 64 bit integer).

   In any case, I agree that the assumption that longs and ints can be
mutually cast without loss of information is a nasty one which breaks
often. Another bad one is the idea that an integer can always hold a
pointer. I've heard that these are common blights in GNU code, though
I've never tried to verify that.

   Oh, in case people are interested, and don't know, the document which
is going to become the ISO C99 standard, n869, is available at:

http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/

good reading, a bit low on plot development.


-- 
 Christopher Neufeld		   Christopher.Neufeld@dynacan.org
 Home page:  http://caliban.physics.utoronto.ca/neufeld/
 "Don't edit reality for the sake of simplicity"