All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [parisc-linux] Some PA-RISC 2.0 Gotchas
@ 2000-02-11 18:38 Christopher Neufeld
  2000-02-11 19:18 ` [parisc-linux] Building the PA-RISC 2.0 kernel with the GCC tool chain Ullas Ponnadi
  0 siblings, 1 reply; 2+ messages in thread
From: Christopher Neufeld @ 2000-02-11 18:38 UTC (permalink / raw)
  To: parisc-linux

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"

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [parisc-linux] Building the PA-RISC 2.0 kernel with the GCC tool chain
  2000-02-11 18:38 [parisc-linux] Some PA-RISC 2.0 Gotchas Christopher Neufeld
@ 2000-02-11 19:18 ` Ullas Ponnadi
  0 siblings, 0 replies; 2+ messages in thread
From: Ullas Ponnadi @ 2000-02-11 19:18 UTC (permalink / raw)
  Cc: parisc-linux

John Curry and myself have been looking at the PA-RISC 2.0 Port. Here are
some things that I have tried using the latest GCC tool chain.

- I have been able to build an ELF-64 binary using the tool chain. The tools
that
  I have used are:
        - gcc version 2.9-hppa-991112
        - GNU ld version 2.9-hppa-991112 (with BFD 2.9-hppa-991112)
        - GNU Make version 3.77

- I have used a bare bone kernel for the build.

- Most of the assembly files are stubbed out since the assembler directives and
in
  some cases, assembly tricks do not work on the 64 bit architecture.

- The purpose of the build was to test the tool chain and deal with any 64 bit
issues,
   so no tests have been done:-).

Hope this information is useful for anyone trying to work on a PA-RISC 2.0
Port.

Ullas

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2000-02-11 21:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-02-11 18:38 [parisc-linux] Some PA-RISC 2.0 Gotchas Christopher Neufeld
2000-02-11 19:18 ` [parisc-linux] Building the PA-RISC 2.0 kernel with the GCC tool chain Ullas Ponnadi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.