[9fans] 64-Bit programming model.

[9fans] 64-Bit programming model.

[Vester Thacker]

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

Re: [9fans] 64-Bit programming model.

[Charles Forsyth]

[-- 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

Re: [9fans] 64-Bit programming model.

[David Leimbach]

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".

Re: [9fans] 64-Bit programming model.

[Karl Magdsick]

[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
>
>

Re: [9fans] 64-Bit programming model.

[Charles Forsyth]

[-- 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
>
>

Re: [9fans] 64-Bit programming model.

[Karl Magdsick]

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.
>

Re: [9fans] 64-Bit programming model.

[Russ Cox]

> Are there also equivalents of int_lest32_t, uint_fast16_t, float_t,
> double_t, etc?

Sure - int, int, double, and double.

Russ

Re: [9fans] 64-Bit programming model.

[bakul+plan9]

> 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)

Re: [9fans] 64-Bit programming model.

[Devon H. O'Dell]

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
>
>

Re: [9fans] 64-Bit programming model.

[Charles Forsyth]

> 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!

Re: [9fans] 64-Bit programming model.

[erik quanstrom]

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!

Re: [9fans] 64-Bit programming model.

[Charles Forsyth]

| 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.

Re: [9fans] 64-Bit programming model.

[Ronald G Minnich]

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

Re: [9fans] 64-Bit programming model.

[Vester Thacker]

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

Re: [9fans] 64-Bit programming model.

[Jim McKie]

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

Re: [9fans] 64-Bit programming model.

[Ronald G Minnich]

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

Re: [9fans] 64-Bit programming model.

[Devon H. O'Dell]

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

Re: [9fans] 64-Bit programming model.

[erik quanstrom]

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

Re: [9fans] 64-Bit programming model.

[Jim McKie]

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

Re: [9fans] 64-Bit programming model.

[erik quanstrom]

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

Re: [9fans] 64-Bit programming model.

[Russ Cox]

> 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

Re: [9fans] 64-Bit programming model.

[Devon H. O'Dell]

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

Re: [9fans] 64-Bit programming model.

[Charles Forsyth]

> 	... 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.

Re: [9fans] 64-Bit programming model.

[Charles Forsyth]

> 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.