Re: ArchitectureSpecificsMemo
Hi, On Thu, Nov 27, 2014 at 10:50:26AM +, Edmund Grimley Evans wrote: http://wiki.debian.org/ArchitectureSpecificsMemo Some suggestions for improving this table: 1. About half of the table is taken up with sizeof information, some of which could be expressed more concisely. (Are all Debian architectures ILP32 or LP64? Any rare exceptions could be described in a footnote.) Right. Also the recently added float/double/long double columns can be reduced to to a float parameters passed via column, since all three kind of floats are passed same way. 2. Perhaps it would be better to reverse the axes, particularly if the sizeof information is simplified and as more and more architectures are added. Ok, makes sense - it also easier to see what arch the actual edit touched when getting wiki notifications. I also approve how you changed char,endian and stack direction back to words instead of single letters. now one doesn't have to read the legend all the time! 3. A link to a list of system calls might be useful for some people. probably for some other page. 4. I'd like to see some information about va_list added as this sometimes causes portability problems. For example: I think it's unwise - to rephrase what Thorsten said, we shouldn't encourage people to depend on the internals of va_list but use the va_list api functions and not make assumptions. Another page documenting va_list differences on architectures might make sense. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141128125024.ga6...@afflict.kos.to
ArchitectureSpecificsMemo
http://wiki.debian.org/ArchitectureSpecificsMemo
Some suggestions for improving this table:
1. About half of the table is taken up with sizeof information, some
of which could be expressed more concisely. (Are all Debian
architectures ILP32 or LP64? Any rare exceptions could be described in
a footnote.)
2. Perhaps it would be better to reverse the axes, particularly if the
sizeof information is simplified and as more and more architectures
are added.
3. A link to a list of system calls might be useful for some people.
4. I'd like to see some information about va_list added as this
sometimes causes portability problems. For example:
On amd64, va_list is a (struct { ... } [1]) with size 24 and alignment
8. (It's an array, so it turns into a pointer in some circumstances.
You can test whether a va_list is equal to zero, for example.)
On arm64, va_list is a (struct { ... }) with size 32 and alignment 8.
(It's not an array. You can't test whether it's zero.)
On armhf, va_list is a (struct { ...}) with size 4 and alignment 4.
(Have I got that right?)
On i386, va_list is a (char *).
Any thoughts? Vehement objections?
Edmund
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAHDciUdZ4Jmn89Y6Q6ZSMUhgWwn+X5g3R3zxy3ga=FzqjT=j...@mail.gmail.com
Re: ArchitectureSpecificsMemo
On Thu, 27 Nov 2014, Edmund Grimley Evans wrote: of which could be expressed more concisely. (Are all Debian architectures ILP32 or LP64? Any rare exceptions could be described in I think so. Probably even all Linux architectures? 4. I'd like to see some information about va_list added as this sometimes causes portability problems. For example: TTBOMK va_list is opaque, you may not do that anyway. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411271238420.28...@tglase.lan.tarent.de
Re: ArchitectureSpecificsMemo
On Thu, Nov 27, 2014 at 10:50:26 +, Edmund Grimley Evans wrote:
http://wiki.debian.org/ArchitectureSpecificsMemo
Some suggestions for improving this table:
1. About half of the table is taken up with sizeof information, some
of which could be expressed more concisely. (Are all Debian
architectures ILP32 or LP64? Any rare exceptions could be described in
a footnote.)
2. Perhaps it would be better to reverse the axes, particularly if the
sizeof information is simplified and as more and more architectures
are added.
3. A link to a list of system calls might be useful for some people.
4. I'd like to see some information about va_list added as this
sometimes causes portability problems. For example:
On amd64, va_list is a (struct { ... } [1]) with size 24 and alignment
8. (It's an array, so it turns into a pointer in some circumstances.
You can test whether a va_list is equal to zero, for example.)
On arm64, va_list is a (struct { ... }) with size 32 and alignment 8.
(It's not an array. You can't test whether it's zero.)
On armhf, va_list is a (struct { ...}) with size 4 and alignment 4.
(Have I got that right?)
On i386, va_list is a (char *).
Any thoughts? Vehement objections?
As this is one of the wiki pages that I visit most often: I'd completely agree,
and addition it would be very useful if the macros defined by compilers we use
(GCC, and maybe Clang) to test for a particular architecture were listed as
well. (Yes, we're in do-ocracy, so I should just go and add these...)
Best,
Michael
pgpLAeL93Fj4X.pgp
Description: PGP signature
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
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 Description: This is a digitally signed message part
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
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 Description: This is a digitally signed message part
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Sat, 2008-04-26 at 20:21 +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] 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 Description: This is a digitally signed message part
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
* Bernd Eckenfels: In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
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. pgpy0wEHuCkK7.pgp Description: PGP signature
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
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 Description: Digital signature
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
[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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
