* [9fans] 64-Bit programming model. @ 2005-09-30 11:31 Vester Thacker 2005-09-30 13:31 ` Charles Forsyth [not found] ` <f344c691fd8960b43b2c77f308ed2ea3@terzarima.net> 0 siblings, 2 replies; 24+ messages in thread From: Vester Thacker @ 2005-09-30 11:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Okay, time for the "dumb question of the month". Concerning Plan 9 64-Bit support, which Long Pointer programming model is being used with Sparc64 and AMD64 ports? LLP64, LP64 or ILP64. Just curious. Forgive my ignorance, I am a layman and nowadays get my schooling though search engine results. --vester ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 11:31 [9fans] 64-Bit programming model Vester Thacker @ 2005-09-30 13:31 ` Charles Forsyth 2005-09-30 15:18 ` David Leimbach ` (2 more replies) [not found] ` <f344c691fd8960b43b2c77f308ed2ea3@terzarima.net> 1 sibling, 3 replies; 24+ messages in thread From: Charles Forsyth @ 2005-09-30 13:31 UTC (permalink / raw) To: vester.thacker, 9fans [-- Attachment #1: Type: text/plain, Size: 263 bytes --] on amd64 it is: short is 16 bits, as before for Plan 9 int and long are 32 bits, as before long long is 64 bits, also as before pointers are 64 bits, not as before. (it's that last bit causes most of the trouble.) i think it must be LLP64 in your scheme [-- Attachment #2: Type: message/rfc822, Size: 3157 bytes --] From: Vester Thacker <vester.thacker@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: [9fans] 64-Bit programming model. Date: Fri, 30 Sep 2005 04:31:45 -0700 Message-ID: <32a656c20509300431j6ab02b7cm7512019149d45a59@mail.gmail.com> Okay, time for the "dumb question of the month". Concerning Plan 9 64-Bit support, which Long Pointer programming model is being used with Sparc64 and AMD64 ports? LLP64, LP64 or ILP64. Just curious. Forgive my ignorance, I am a layman and nowadays get my schooling though search engine results. --vester ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 13:31 ` Charles Forsyth @ 2005-09-30 15:18 ` David Leimbach 2005-09-30 15:44 ` Karl Magdsick 2005-09-30 16:14 ` Devon H. O'Dell 2 siblings, 0 replies; 24+ messages in thread From: David Leimbach @ 2005-09-30 15:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 9/30/05, Charles Forsyth <forsyth@terzarima.net> wrote: > on amd64 it is: > > short is 16 bits, as before for Plan 9 > int and long are 32 bits, as before > long long is 64 bits, also as before > pointers are 64 bits, not as before. (it's that last bit causes most of the trouble.) > i think it must be LLP64 in your scheme > Basically "the same as windows 64". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 13:31 ` Charles Forsyth 2005-09-30 15:18 ` David Leimbach @ 2005-09-30 15:44 ` Karl Magdsick 2005-09-30 16:06 ` Charles Forsyth [not found] ` <45544405a9a74e554cd5b645a672fb3e@terzarima.net> 2005-09-30 16:14 ` Devon H. O'Dell 2 siblings, 2 replies; 24+ messages in thread From: Karl Magdsick @ 2005-09-30 15:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [obligatory plug for C99 types] u_int8_t, int32_t, u_int32_t, int64_t, u_int64_t, etc. are for use in code that is dependent upon integer width. [/obligatory plug for C99 types] -Karl On 9/30/05, Charles Forsyth <forsyth@terzarima.net> wrote: > on amd64 it is: > > short is 16 bits, as before for Plan 9 > int and long are 32 bits, as before > long long is 64 bits, also as before > pointers are 64 bits, not as before. (it's that last bit causes most of the trouble.) > i think it must be LLP64 in your scheme > > > > ---------- Forwarded message ---------- > From: Vester Thacker <vester.thacker@gmail.com> > To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> > Date: Fri, 30 Sep 2005 04:31:45 -0700 > Subject: [9fans] 64-Bit programming model. > Okay, time for the "dumb question of the month". > > Concerning Plan 9 64-Bit support, which Long Pointer programming model > is being used with Sparc64 and AMD64 ports? LLP64, LP64 or ILP64. Just > curious. > > Forgive my ignorance, I am a layman and nowadays get my schooling > though search engine results. > > --vester > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 15:44 ` Karl Magdsick @ 2005-09-30 16:06 ` Charles Forsyth [not found] ` <45544405a9a74e554cd5b645a672fb3e@terzarima.net> 1 sibling, 0 replies; 24+ messages in thread From: Charles Forsyth @ 2005-09-30 16:06 UTC (permalink / raw) To: kmagnum, 9fans [-- Attachment #1: Type: text/plain, Size: 229 bytes --] plan 9 code has u32int, u64int etc which is still rather ugly but easier to speak without stammering, and is mainly confined to code that requires particular widths. the integer type big enough to hold a pointer is uintptr. [-- Attachment #2: Type: message/rfc822, Size: 4172 bytes --] From: Karl Magdsick <kmagnum@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] 64-Bit programming model. Date: Fri, 30 Sep 2005 11:44:25 -0400 Message-ID: <cd8ecdef0509300844x6e2ae08csbe97ede3b2cff972@mail.gmail.com> [obligatory plug for C99 types] u_int8_t, int32_t, u_int32_t, int64_t, u_int64_t, etc. are for use in code that is dependent upon integer width. [/obligatory plug for C99 types] -Karl On 9/30/05, Charles Forsyth <forsyth@terzarima.net> wrote: > on amd64 it is: > > short is 16 bits, as before for Plan 9 > int and long are 32 bits, as before > long long is 64 bits, also as before > pointers are 64 bits, not as before. (it's that last bit causes most of the trouble.) > i think it must be LLP64 in your scheme > > > > ---------- Forwarded message ---------- > From: Vester Thacker <vester.thacker@gmail.com> > To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> > Date: Fri, 30 Sep 2005 04:31:45 -0700 > Subject: [9fans] 64-Bit programming model. > Okay, time for the "dumb question of the month". > > Concerning Plan 9 64-Bit support, which Long Pointer programming model > is being used with Sparc64 and AMD64 ports? LLP64, LP64 or ILP64. Just > curious. > > Forgive my ignorance, I am a layman and nowadays get my schooling > though search engine results. > > --vester > > ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <45544405a9a74e554cd5b645a672fb3e@terzarima.net>]
* Re: [9fans] 64-Bit programming model. [not found] ` <45544405a9a74e554cd5b645a672fb3e@terzarima.net> @ 2005-09-30 16:14 ` Karl Magdsick 2005-09-30 16:21 ` Russ Cox 2005-09-30 16:53 ` bakul+plan9 0 siblings, 2 replies; 24+ messages in thread From: Karl Magdsick @ 2005-09-30 16:14 UTC (permalink / raw) To: 9fans Cool. Are there also equivalents of int_lest32_t, uint_fast16_t, float_t, double_t, etc? -Karl On 9/30/05, Charles Forsyth <forsyth@terzarima.net> wrote: > plan 9 code has u32int, u64int etc > which is still rather ugly but easier to speak > without stammering, and is mainly confined to > code that requires particular widths. > the integer type big enough to hold a pointer is uintptr. > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 16:14 ` Karl Magdsick @ 2005-09-30 16:21 ` Russ Cox 2005-09-30 16:53 ` bakul+plan9 1 sibling, 0 replies; 24+ messages in thread From: Russ Cox @ 2005-09-30 16:21 UTC (permalink / raw) To: Karl Magdsick, Fans of the OS Plan 9 from Bell Labs > Are there also equivalents of int_lest32_t, uint_fast16_t, float_t, > double_t, etc? Sure - int, int, double, and double. Russ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 16:14 ` Karl Magdsick 2005-09-30 16:21 ` Russ Cox @ 2005-09-30 16:53 ` bakul+plan9 1 sibling, 0 replies; 24+ messages in thread From: bakul+plan9 @ 2005-09-30 16:53 UTC (permalink / raw) To: Karl Magdsick, Fans of the OS Plan 9 from Bell Labs > Are there also equivalents of int_lest32_t, uint_fast16_t, float_t, > double_t, etc? Sure! FIXED BIN(63,31) FIXED BIN(16) FLOAT BIN(21) FLOAT BIN(53) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 13:31 ` Charles Forsyth 2005-09-30 15:18 ` David Leimbach 2005-09-30 15:44 ` Karl Magdsick @ 2005-09-30 16:14 ` Devon H. O'Dell 2005-09-30 18:07 ` Charles Forsyth 2 siblings, 1 reply; 24+ messages in thread From: Devon H. O'Dell @ 2005-09-30 16:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2005/9/30, Charles Forsyth <forsyth@terzarima.net>: > on amd64 it is: > > short is 16 bits, as before for Plan 9 > int and long are 32 bits, as before > long long is 64 bits, also as before > pointers are 64 bits, not as before. (it's that last bit causes most of the trouble.) Yeah, way too much code in Unix that uses void pointer to integer casting. ``Oops''. > i think it must be LLP64 in your scheme At least in Solaris the #define for both amd64 and SPARC64 is `LP64'. This is found in one of the include files under feature_tests.h (see cvs.opensolaris.org). --Devon > > > ---------- Doorgestuurd bericht ---------- > From: Vester Thacker <vester.thacker@gmail.com> > To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> > Date: Fri, 30 Sep 2005 04:31:45 -0700 > Subject: [9fans] 64-Bit programming model. > Okay, time for the "dumb question of the month". > > Concerning Plan 9 64-Bit support, which Long Pointer programming model > is being used with Sparc64 and AMD64 ports? LLP64, LP64 or ILP64. Just > curious. > > Forgive my ignorance, I am a layman and nowadays get my schooling > though search engine results. > > --vester > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 16:14 ` Devon H. O'Dell @ 2005-09-30 18:07 ` Charles Forsyth 2005-09-30 19:01 ` erik quanstrom 0 siblings, 1 reply; 24+ messages in thread From: Charles Forsyth @ 2005-09-30 18:07 UTC (permalink / raw) To: devon.odell, 9fans > At least in Solaris the #define for both amd64 and SPARC64 is `LP64'. > This is found in one of the include files under feature_tests.h (see > cvs.opensolaris.org). yes, they went for the model where long changes size like pointers. the difference is that relatively few applications see pointer representations but quite a few rely on shifts, masks, etc. of `long' that are functions of 32 not 64. but obviously enough ifdefs will compensate for everything, as usual! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 18:07 ` Charles Forsyth @ 2005-09-30 19:01 ` erik quanstrom 2005-10-01 13:52 ` Charles Forsyth 0 siblings, 1 reply; 24+ messages in thread From: erik quanstrom @ 2005-09-30 19:01 UTC (permalink / raw) To: devon.odell, Charles Forsyth, 9fans actually, i think it's worse than that. enough #ifdefs will make a given set of programs work, after much hand tweaking, but for each new program, you need to add even more #ifdefs. Charles Forsyth <forsyth@terzarima.net> writes | | > At least in Solaris the #define for both amd64 and SPARC64 is `LP64'. | > This is found in one of the include files under feature_tests.h (see | > cvs.opensolaris.org). | | yes, they went for the model where long changes size like pointers. | the difference is that relatively few applications see pointer representations | but quite a few rely on shifts, masks, etc. of `long' that are functions of 32 not 64. | | but obviously enough ifdefs will compensate for everything, as usual! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 19:01 ` erik quanstrom @ 2005-10-01 13:52 ` Charles Forsyth 2005-10-01 23:37 ` Ronald G Minnich 0 siblings, 1 reply; 24+ messages in thread From: Charles Forsyth @ 2005-10-01 13:52 UTC (permalink / raw) To: quanstro, 9fans | but obviously enough ifdefs will compensate for everything, as usual! > actually, i think it's worse than that. enough #ifdefs will make a given > set of programs work, after much hand tweaking, but for each new > program, you need to add even more #ifdefs. i know. i was being sarcastic, especially since i've been wading (verb doesn't quite capture the feeling) through linux kernel headers and code. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 13:52 ` Charles Forsyth @ 2005-10-01 23:37 ` Ronald G Minnich 0 siblings, 0 replies; 24+ messages in thread From: Ronald G Minnich @ 2005-10-01 23:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: quanstro Charles Forsyth wrote: > i know. i was being sarcastic, especially since i've been wading > (verb doesn't quite capture the feeling) through linux kernel headers and code. > ooh, yeah. When is a function call not a function call? When, after wading through 6 or 8 .h files, you find it is #define x() Well, admittedly, linux has a lot of tough problems to solve, but I just can't get myself to like this style. ron ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <f344c691fd8960b43b2c77f308ed2ea3@terzarima.net>]
* Re: [9fans] 64-Bit programming model. [not found] ` <f344c691fd8960b43b2c77f308ed2ea3@terzarima.net> @ 2005-09-30 21:27 ` Vester Thacker 2005-09-30 23:28 ` Jim McKie 2005-10-01 14:20 ` Charles Forsyth 0 siblings, 2 replies; 24+ messages in thread From: Vester Thacker @ 2005-09-30 21:27 UTC (permalink / raw) To: Charles Forsyth; +Cc: 9fans On 9/30/05, Charles Forsyth <forsyth@terzarima.net> wrote: > on amd64 it is: > > short is 16 bits, as before for Plan 9 > int and long are 32 bits, as before > long long is 64 bits, also as before > pointers are 64 bits, not as before. (it's that last bit causes most of the trouble.) > i think it must be LLP64 in your scheme Thanks, Charles. Sorry, I forgot to mention the article that led to my earlier question: http://www.unix.org/version2/whatsnew/lp64_wp.html Perhaps it is just a propaganda piece, but I can't discern the difference. I suppose there are many valid reasons to use LLP64 over LP64. Anyhow, I am just being curious and poking things with a stick rather than implying any criticism. --vester ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 21:27 ` Vester Thacker @ 2005-09-30 23:28 ` Jim McKie 2005-10-01 3:09 ` Ronald G Minnich 2005-10-01 14:28 ` Charles Forsyth 2005-10-01 14:20 ` Charles Forsyth 1 sibling, 2 replies; 24+ messages in thread From: Jim McKie @ 2005-09-30 23:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 30 Sep 2005 17:27:49 -0400, Vester Thacker <vester.thacker@gmail.com> wrote: > ... > Sorry, I forgot to mention the article that led to my earlier > question: http://www.unix.org/version2/whatsnew/lp64_wp.html > Perhaps it is just a propaganda piece, but I can't discern the difference. > I suppose there are many valid reasons to use LLP64 over LP64. Anyhow, > I am just being curious and poking things with a stick rather than > implying any criticism. > > --vester > That article dates from 1997-98. It says: ... are best served if there is a single choice widespread in the emerging 64-bit systems. This removes a source of subtle errors in porting to a 64-bit environment, and encourages more rapid exploitation of the technology options. I think that's backwards, you get sloppy in a monoculture. --jim ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 23:28 ` Jim McKie @ 2005-10-01 3:09 ` Ronald G Minnich 2005-10-01 3:19 ` Devon H. O'Dell 2005-10-01 14:28 ` Charles Forsyth 1 sibling, 1 reply; 24+ messages in thread From: Ronald G Minnich @ 2005-10-01 3:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Jim McKie wrote: > > ... are best served if there is a single choice widespread in the > > emerging 64-bit systems. This removes a source of subtle errors in > > porting to a 64-bit environment, and encourages more rapid > > exploitation of the technology options. > > I think that's backwards, you get sloppy in a monoculture. yeah, good point. We kept our alphas alive here for a long time for one reason: to make sure they kept us honest. For one thing, they would really complain about bad alighment. Pentiums are way too kind when you do something stupid like misalign a long or vlong. I was sad when it came time to turn them off. It's too easy to be stupid with just one architecture. ron ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 3:09 ` Ronald G Minnich @ 2005-10-01 3:19 ` Devon H. O'Dell 2005-10-01 4:46 ` erik quanstrom 2005-10-01 13:50 ` Russ Cox 0 siblings, 2 replies; 24+ messages in thread From: Devon H. O'Dell @ 2005-10-01 3:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2005/9/30, Ronald G Minnich <rminnich@lanl.gov>: > Jim McKie wrote: > > > > ... are best served if there is a single choice widespread in the > > > emerging 64-bit systems. This removes a source of subtle errors in > > > porting to a 64-bit environment, and encourages more rapid > > > exploitation of the technology options. > > > > I think that's backwards, you get sloppy in a monoculture. > > yeah, good point. We kept our alphas alive here for a long time for one > reason: to make sure they kept us honest. For one thing, they would > really complain about bad alighment. Pentiums are way too kind when you > do something stupid like misalign a long or vlong. > > I was sad when it came time to turn them off. > > It's too easy to be stupid with just one architecture. > > ron I just ran into an alignment bug yesterday doing credential passing over Unix Domain Sockets on amd64. Admittedly, I should have read the RFC (and more of the sunrpc code, which is where I stole mine from), but it is really easy to run into alignment issues when you're only using one architecture. Though I don't necessarily agree with Jim if I understand him correctly. I don't think that providing interfaces to make code compilation on systems of different bit sizes promotes `a sloppy monoculture.' --Devon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 3:19 ` Devon H. O'Dell @ 2005-10-01 4:46 ` erik quanstrom 2005-10-01 22:50 ` Jim McKie 2005-10-01 13:50 ` Russ Cox 1 sibling, 1 reply; 24+ messages in thread From: erik quanstrom @ 2005-10-01 4:46 UTC (permalink / raw) To: Devon H. O'Dell, 9fans i think the point is that there will always be a new chip or machine out there that will force you to use a different model so trying to pretend that everything works the same is bad thinking. all the world's a vax ... hey, wait a minute. i've done this once before. erik "Devon H. O'Dell" <devon.odell@gmail.com> writes | Though I don't necessarily agree with Jim if I understand him | correctly. I don't think that providing interfaces to make code | compilation on systems of different bit sizes promotes `a sloppy | monoculture.' | | --Devon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 4:46 ` erik quanstrom @ 2005-10-01 22:50 ` Jim McKie 2005-10-01 23:43 ` erik quanstrom 0 siblings, 1 reply; 24+ messages in thread From: Jim McKie @ 2005-10-01 22:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, 01 Oct 2005 00:46:21 -0400, erik quanstrom <quanstro@quanstro.net> wrote: > ... > > all the world's a vax ... hey, wait a minute. i've done this once before. > > erik this won't be new to some of you, but i actually saw one of these for sale in a supermarket yesterday: http://www.vax.co.uk/6140.asp ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 22:50 ` Jim McKie @ 2005-10-01 23:43 ` erik quanstrom 0 siblings, 0 replies; 24+ messages in thread From: erik quanstrom @ 2005-10-01 23:43 UTC (permalink / raw) To: Jim McKie, 9fans 1300W. oh, come on. what kind of wimpy machine is that! the vax 11/780s that were my introduction to unix needed 1300W to power the pdp boot processor. and that was 1988. - erik "Jim McKie" <jmk@plan9.bell-labs.com> writes | | On Sat, 01 Oct 2005 00:46:21 -0400, erik quanstrom <quanstro@quanstro.net> wrote: | | > ... | > | > all the world's a vax ... hey, wait a minute. i've done this once before. | > | > erik | | this won't be new to some of you, but i actually saw | one of these for sale in a supermarket yesterday: | | http://www.vax.co.uk/6140.asp ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 3:19 ` Devon H. O'Dell 2005-10-01 4:46 ` erik quanstrom @ 2005-10-01 13:50 ` Russ Cox 2005-10-01 18:28 ` Devon H. O'Dell 1 sibling, 1 reply; 24+ messages in thread From: Russ Cox @ 2005-10-01 13:50 UTC (permalink / raw) To: Devon H. O'Dell, Fans of the OS Plan 9 from Bell Labs > Though I don't necessarily agree with Jim if I understand him > correctly. I don't think that providing interfaces to make code > compilation on systems of different bit sizes promotes `a sloppy > monoculture.' But the quote Jim found wasn't arguing for interfaces. It was arguing for universal agreement on type sizes for 64-bit systems. Russ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-10-01 13:50 ` Russ Cox @ 2005-10-01 18:28 ` Devon H. O'Dell 0 siblings, 0 replies; 24+ messages in thread From: Devon H. O'Dell @ 2005-10-01 18:28 UTC (permalink / raw) To: Russ Cox; +Cc: Fans of the OS Plan 9 from Bell Labs 2005/10/1, Russ Cox <rsc@swtch.com>: > > Though I don't necessarily agree with Jim if I understand him > > correctly. I don't think that providing interfaces to make code > > compilation on systems of different bit sizes promotes `a sloppy > > monoculture.' > > But the quote Jim found wasn't arguing for interfaces. > It was arguing for universal agreement on type sizes for > 64-bit systems. > > Russ In which case this is a misunderstanding on my part :) -D ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 23:28 ` Jim McKie 2005-10-01 3:09 ` Ronald G Minnich @ 2005-10-01 14:28 ` Charles Forsyth 1 sibling, 0 replies; 24+ messages in thread From: Charles Forsyth @ 2005-10-01 14:28 UTC (permalink / raw) To: 9fans > ... are best served if there is a single choice widespread in the > emerging 64-bit systems. This removes a source of subtle errors in > porting to a 64-bit environment, and encourages more rapid > exploitation of the technology options. > > I think that's backwards, you get sloppy in a monoculture. they also seemed to have assumed that 32-bit systems would naturally be left behind. now, with x86, i'd quite like to assume amd64 for ever, but that's not because i get 64 bits, but because i FINALLY GET A FEW ALMOST GENERAL PURPOSE REGISTERS (except: oh, because it's bolted on to the x86 several of those need special handling deep down). in practice, i don't expect to see the last of 32-bit systems for some time. anyway, i might as well wait until the (different) virtualisation schemes hit the shops. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] 64-Bit programming model. 2005-09-30 21:27 ` Vester Thacker 2005-09-30 23:28 ` Jim McKie @ 2005-10-01 14:20 ` Charles Forsyth 1 sibling, 0 replies; 24+ messages in thread From: Charles Forsyth @ 2005-10-01 14:20 UTC (permalink / raw) To: vester.thacker, 9fans > Sorry, I forgot to mention the article that led to my earlier > question: http://www.unix.org/version2/whatsnew/lp64_wp.html yes, i know that one. i don't understand why they so glibly assert that approach is easier, unless they hadn't done enough experimental work, or they were unreasonably fortunate in the body of code they picked. i think there might be a discussion about this wrt plan 9 in the archives. briefly, i tried LP64 first, because of the pointer<->int and system interface points they make, but in fact--that is to say i found out about it by actually trying it on plan 9, ape and other source code--and not just on plan 9, much existing software assumes in subtle ways that long is 32 bits. that's unsurprising given the history of the type (eg, when int was 16 bits). plain `int' tends to be used when no particularly large range is needed. plan 9 code (like pre-LP64 unix code) already uses long long for 64 bits. in fact, one could argue that the LLP64 forces one to consider - how best to write pointer<->int conversions or whether they can be avoided - details of the syscall interfaces that anyway need thought with the move to 64 bits (eg, to retain portability between 32- and 64-bit architectures) as to the latter: when plan 9 changed to 64 bit file sizes and offsets, the interface changed. full stop. various unix systems (i think freebsd is an unusual exception) fussed about trying to preserve both 32- and 64-bit interfaces, with too many #ifdefs and `feature macro' definitions, and the result is a Big Frustrating Mess. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2005-10-01 23:43 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-09-30 11:31 [9fans] 64-Bit programming model Vester Thacker 2005-09-30 13:31 ` Charles Forsyth 2005-09-30 15:18 ` David Leimbach 2005-09-30 15:44 ` Karl Magdsick 2005-09-30 16:06 ` Charles Forsyth [not found] ` <45544405a9a74e554cd5b645a672fb3e@terzarima.net> 2005-09-30 16:14 ` Karl Magdsick 2005-09-30 16:21 ` Russ Cox 2005-09-30 16:53 ` bakul+plan9 2005-09-30 16:14 ` Devon H. O'Dell 2005-09-30 18:07 ` Charles Forsyth 2005-09-30 19:01 ` erik quanstrom 2005-10-01 13:52 ` Charles Forsyth 2005-10-01 23:37 ` Ronald G Minnich [not found] ` <f344c691fd8960b43b2c77f308ed2ea3@terzarima.net> 2005-09-30 21:27 ` Vester Thacker 2005-09-30 23:28 ` Jim McKie 2005-10-01 3:09 ` Ronald G Minnich 2005-10-01 3:19 ` Devon H. O'Dell 2005-10-01 4:46 ` erik quanstrom 2005-10-01 22:50 ` Jim McKie 2005-10-01 23:43 ` erik quanstrom 2005-10-01 13:50 ` Russ Cox 2005-10-01 18:28 ` Devon H. O'Dell 2005-10-01 14:28 ` Charles Forsyth 2005-10-01 14:20 ` Charles Forsyth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).