Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Cyril Brulebois-4
Hi,

I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
(well-)known, and whether its content got reviewed, esp. by porters of
each architecture, who could fix obvious errors or typos, or eventually
add special-cases, exceptions, and the like.

 1. http://wiki.debian.org/ArchitectureSpecificsMemo

Looking at its history, the number of commits is rather low, so it
might be interesting to have some couples of eyes checking that page.

Mraw,
KiBi.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Brian M. Carlson
On Fri, Apr 25, 2008 at 08:12:58AM +0200, Cyril Brulebois wrote:
>Hi,
>
>I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
>(well-)known, and whether its content got reviewed, esp. by porters of
>each architecture, who could fix obvious errors or typos, or eventually
>add special-cases, exceptions, and the like.
>
> 1. http://wiki.debian.org/ArchitectureSpecificsMemo

One other thing that might be useful is alignment for each of 1, 2, 4,
and 8 byte quantities, and the signal used for unaligned accesses.  This
would be useful because it would allow developers to immediately
determine (e.g) what a SIGBUS on sparc means.  Obviously, if a machine
doesn't prohibit unaligned accesses (like the i386) then that field
would be left blank.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Petter Reinholdtsen
In reply to this post by Cyril Brulebois-4
[Cyril Brulebois]
> Hi,
>
> I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
> (well-)known, and whether its content got reviewed, esp. by porters of
> each architecture, who could fix obvious errors or typos, or eventually
> add special-cases, exceptions, and the like.
>
>  1. http://wiki.debian.org/ArchitectureSpecificsMemo

'arm' is said to be LE, but I believe it differ for integers and
floating point numbers.  Is 'arm' in the list the 'arm' archtecture?
What about 'armel' and 'armeb'?  The page should state if the
architecture name is the output from 'dpkg --print-architecture' or
some other value.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Zack Weinberg-2
In reply to this post by Cyril Brulebois-4
I looked at the page: this seems like an appropriate moment to mention
something that should be a lot more widely known than it is:

   sizeof(char) == 1
   sizeof(signed char) == 1
   sizeof(unsigned char) == 1

Those three equalities are not part of any ABI.  They are written into
the C standard, in the definition of the sizeof() operator.  They will
never be false.

zw


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

riku voipio-7
In reply to this post by Petter Reinholdtsen
On Fri, Apr 25, 2008 at 05:06:59PM +0200, Petter Reinholdtsen wrote:
> 'arm' is said to be LE, but I believe it differ for integers and
> floating point numbers.  Is 'arm' in the list the 'arm' archtecture?
> What about 'armel' and 'armeb'?

on arm (unlike armeb and armel), doubles are two little-endian words
stored bigendian.


--
"rm -rf" only sounds scary if you don't have backups


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Florian Weimer
In reply to this post by Cyril Brulebois-4
* Cyril Brulebois:

> I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
> (well-)known, and whether its content got reviewed, esp. by porters of
> each architecture, who could fix obvious errors or typos, or eventually
> add special-cases, exceptions, and the like.

I hope the table can be simplified, along the categories LP32/LP64,
endianness, char signedness.  sizeof(long double) needs to be listed
separately, along with it's range/precision.

Hopefully, we will never end up with an architecture where sizeof(long)
!= sizeof(void *) or sizeof(int) != 4.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Ben Hutchings-3
On Sat, 2008-04-26 at 12:29 +0200, Florian Weimer wrote:

> * Cyril Brulebois:
>
> > I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
> > (well-)known, and whether its content got reviewed, esp. by porters of
> > each architecture, who could fix obvious errors or typos, or eventually
> > add special-cases, exceptions, and the like.
>
> I hope the table can be simplified, along the categories LP32/LP64,
> endianness, char signedness.  sizeof(long double) needs to be listed
> separately, along with it's range/precision.
>
> Hopefully, we will never end up with an architecture where sizeof(long)
> != sizeof(void *)
Linux has a convention predating intptr_t of using long for that
purpose, so Linux won't allow such an ABI.

>  or sizeof(int) != 4.

GNU requires that, unless I'm much mistaken.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Ben Hutchings-3
In reply to this post by Zack Weinberg-2
On Sat, 2008-04-26 at 00:15 -0400, Zack Weinberg wrote:

> I looked at the page: this seems like an appropriate moment to mention
> something that should be a lot more widely known than it is:
>
>    sizeof(char) == 1
>    sizeof(signed char) == 1
>    sizeof(unsigned char) == 1
>
> Those three equalities are not part of any ABI.  They are written into
> the C standard, in the definition of the sizeof() operator.  They will
> never be false.
I just removed them for this reason.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Bernd Eckenfels
In article <[hidden email]> you wrote:
>>    sizeof(char) == 1

> I just removed them for this reason.

Maybe we need to specify CHAR_BITS instead?

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Ben Hutchings-3
On Sat, 2008-04-26 at 20:21 +0200, Bernd Eckenfels wrote:
> In article <[hidden email]> you wrote:
> >>    sizeof(char) == 1
>
> > I just removed them for this reason.
>
> Maybe we need to specify CHAR_BITS instead?

Maybe some day Debian will run on an architecture where CHAR_BITS != 8,
but I doubt it; too much software depends on having exactly-8-bit types.
Until then, why bother?  (Similarly there's little point in including
sizeof(short) and sizeof(int); they don't vary between our current
architectures and are very unlikely to do so in future.)

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

Florian Weimer
In reply to this post by Bernd Eckenfels
* Bernd Eckenfels:

> In article <[hidden email]> you wrote:
>>>    sizeof(char) == 1
>
>> I just removed them for this reason.
>
> Maybe we need to specify CHAR_BITS instead?

Too much Java programming? 8-)

POSIX requires CHAR_BITS to be 8 these days.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]