[9fans] Sleep-complexity

[9fans] Sleep-complexity

[Christoph Lohmann]

Good day.

Just do be sure that there is no scientifc paper that describes the pro
of using for() in sleep(2), as an architecture decision:

% cat /n/sources/plan9/sys/src/cmd/sleep.c
#include <u.h>
#include <libc.h>

void
main(int argc, char *argv[])
{
	long secs;

	if(argc>1)
		for(secs = atol(argv[1]); secs > 0; secs--)
			sleep(1000);
	exits(0);
}

% cat /sys/src/cmd/sleep.c
#include <u.h>
#include <libc.h>

void
main(int argc, char *argv[])
{

	if(argc>1)
		sleep(atol(argv[1]) * 1000);

	exits(0);
}

% ls -l /386/bin/sleep /386/bin/_sleep
--rwxrwxr-x M 8 none sys 3409 May  8  13:43 /386/bin/_sleep
--rwxrwxr-x M 8 sys  sys 3390 Max  8  13:44 /386/bin/sleep

Is there any reason for the for()-loop?

Sincerely,

Christoph

Re: [9fans] Sleep-complexity

[Sergey Reva]

Hello Fans,

> Is there any reason for the for()-loop?
Without 'for' you can't call:
sleep max-long-value

I wont also add question:

sysproc.c:
> long
> syssleep(ulong *arg)
> {
>       int n;
>       n = arg[0];
>

man 2 sleep
> int sleep(long millisecs)

Why 'n' not defined as long?

-- 
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Sleep-complexity

[Russ Cox]

> Why 'n' not defined as long?

because long and int are the same so it really doesn't matter.

Re: [9fans] Sleep-complexity

[Dan Cross]

On Sun, May 08, 2005 at 12:50:58PM -0400, Russ Cox wrote:
> > Why 'n' not defined as long?
> 
> because long and int are the same so it really doesn't matter.

That's not a terribly great assumption to make, is it?

	- Dan C.

Re: [9fans] Sleep-complexity

[jmk]

On Sun May  8 13:29:11 EDT 2005, cross@math.psu.edu wrote:
> On Sun, May 08, 2005 at 12:50:58PM -0400, Russ Cox wrote:
> > > Why 'n' not defined as long?
> > 
> > because long and int are the same so it really doesn't matter.
> 
> That's not a terribly great assumption to make, is it?
> 
> 	- Dan C.

It would take a lot of work get get Plan9 to work on a
machine where that isn't the case, and I don't see anyone
jumping up to do it.

Re: [9fans] Sleep-complexity

[Bruce Ellis]

Kinda reminds me of RedHat for the Alpha.  Everything compiled
and was distributed.  It's just that a lot of things didn't work because
of 64 vs 32 bit not to mention that user address space started
at 0x100000000.  The worst hit was the networking code.
I'm sure things are *better* now - certainly the second release
I tried had a different set of non-functioning programs.

dhog's plan9 was a better choice.

brucee

On 5/9/05, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
> On Sun May  8 13:29:11 EDT 2005, cross@math.psu.edu wrote:
> > On Sun, May 08, 2005 at 12:50:58PM -0400, Russ Cox wrote:
> > > > Why 'n' not defined as long?
> > >
> > > because long and int are the same so it really doesn't matter.
> >
> > That's not a terribly great assumption to make, is it?
> >
> >       - Dan C.
> 
> It would take a lot of work get get Plan9 to work on a
> machine where that isn't the case, and I don't see anyone
> jumping up to do it.
>

Re: [9fans] Sleep-complexity

[Charles Forsyth]

>>dhog's plan9 was a better choice.

yes, and it seems to be the correct one for most systems, given
existing software -- not just Plan 9, but including Linux --
but evidently some people enjoy inflicting needless pain.

Re: [9fans] Sleep-complexity

[Charles Forsyth]

>>but evidently some people enjoy inflicting needless pain.

another example is the filth surrounding 64 bit file sizes and offsets on 'nix.
(give me strength.)

during the early streams/socket wars someone coined the term
`incompatibility library'.  that's one that purports to provide compatibility
with another interface so you can use your existing source and binaries but gets it wrong
enough that you need to change and recompile them anyway,
so that you didn't need the library.

Re: [9fans] Sleep-complexity

[Dan Cross]

On Sun, May 08, 2005 at 02:56:15PM -0400, jmk@plan9.bell-labs.com wrote:
> > > because long and int are the same so it really doesn't matter.
> > 
> > That's not a terribly great assumption to make, is it?
> 
> It would take a lot of work get get Plan9 to work on a
> machine where that isn't the case, and I don't see anyone
> jumping up to do it.

That's true, but I still wouldn't go as far as sanctioning the
practice.  Also, a fair amount of Plan 9 code is now running under
various other platforms where that's not necessarily the case via
plan9ports.

Charles's point about the subtleness of type-sizing not withstanding
(in the original case, someone was passing an int in place of a long,
which would be promoted automatically), it's still something one should
be careful about.  All the world is no longer a 32-bit 386.

	- Dan C.

Re: [9fans] Sleep-complexity

[geoff]

> All the world is no longer a 32-bit 386.

True, but the pain of the PDP-11-to-VAX migration, when `int' changed
from 16 bits to 32, seems to have convinced the standards
organisations that they don't want to change the sizes of any integral
types.  The proposed sizes for 64-bit implementations (in `LLP64')
are: 32 bits for int and long, 64 for long long and pointers.  And
ANSI & POSIX will continue to paper over size differences with *_t
types.

I'd prefer 64-bit longs and no long longs (or 128-bit long longs), but
that seems unlikely given the vast existing corpus of code written
without much attention to types.

Re: [9fans] Sleep-complexity

[Richard Miller]

> True, but the pain of the PDP-11-to-VAX migration, when `int' changed
> from 16 bits to 32

s/VAX/Interdata/

-- Richard

Re: [9fans] Sleep-complexity

[Brantley Coile]

In thinking about char, short, int, long, long long, it appears that
int is an exception.  It was supposed to be the natural machine word.
Plan 9 uses int, as stated earlier, mostly in loop counters and such
things.  In that case making int be 64 bits on 64 bit machines would
make sense only if loading and storing 64 bits was the just as fast at
32 bits.  I don't think I need 64 bits to count to 1000.

My main point here is that types describe various sizes of intergers
available in a machine.  If the machine can do four sizes of integers,
then C needs four types to specify them.

 Brantley

Re: [9fans] Sleep-complexity

[Mike Haertel]

>> All the world is no longer a 32-bit 386.
>
>True, but the pain of the PDP-11-to-VAX migration, when `int' changed
>from 16 bits to 32, seems to have convinced the standards
>organisations that they don't want to change the sizes of any integral
>types.  The proposed sizes for 64-bit implementations (in `LLP64')
>are: 32 bits for int and long, 64 for long long and pointers.  And
>ANSI & POSIX will continue to paper over size differences with *_t
>types.
>
>I'd prefer 64-bit longs and no long longs (or 128-bit long longs), but
>that seems unlikely given the vast existing corpus of code written
>without much attention to types.

Wow, you're a little out of date.

The *BSDs and Linux did the Right Thing: on Alpha and AMD64
(the two flavors of which I have personal knowledge) "long"
is 64 bits.

So the vast corpus of software that has been ported to
64-bit *BSD and Linux systems is now free of the assumption
that sizeof (int) == sizeof (long).

There is still a pervasive assumption that ints are 32 bits.

Re: [9fans] Sleep-complexity

[Bruce Ellis]

I'm out of date?  RedHat still doesn't *work* on the alpha?!

I don't know what the *right thing* is but shipping code that
compiles but doesn't work ain't it.

brucee

> Wow, you're a little out of date.
> 
> The *BSDs and Linux did the Right Thing: on Alpha and AMD64
> (the two flavors of which I have personal knowledge) "long"
> is 64 bits.
> 
> So the vast corpus of software that has been ported to
> 64-bit *BSD and Linux systems is now free of the assumption
> that sizeof (int) == sizeof (long).
> 
> There is still a pervasive assumption that ints are 32 bits.

Re: [9fans] Sleep-complexity

[Charles Forsyth]

>>I don't know what the *right thing* is but shipping code that
>>compiles but doesn't work ain't it.

i also looked at the most up-to-date versions of several utilities
and they do not, in fact, do the `right thing'.

i mentioned `incompatibility libraries'?  well, there's a technique with
wider scope.  that's where you get everyone to change their programs to
leave things in nearly the same shape (except perhaps for bugs introduced thereby).
(Governments are prone to this.)

``Something must be done.  This is something.  Therefore we must do it.'' -- Yes, Prime Minister

Re: [9fans] Sleep-complexity

[David Tolpin]

>  All the world is no longer a 32-bit 386.
>

640 kilobytes of RAM is enough for everybody.

Re: [9fans] Sleep-complexity

[Charles Forsyth]

>> because long and int are the same so it really doesn't matter.

>That's not a terribly great assumption to make, is it?

the assumption usually made in practice is a little more subtle:
int <= long[=32] < long long [=64].  most older programs tended
to use int for things such as for loop values, that probably needed to be
at least 16 bits, but might not need to be as much as 32.
by contrast, a `long' quite often needed to be 32 bits, and often
that was `no more, no less'.

it's historically consistent and works well enough.
u32int etc are used a bit more these days, but not
exclusively.

the other subtle assumptions concern pointers and integers.
as it happens, the best choice there is happily consistent with dhog's, although
he didn't face that problem in his alpha port.  it does need source
code changes, but with care, they tend to be fairly limited, outside the kernel.

Re: [9fans] Sleep-complexity

[Nigel Roles]

>the assumption usually made in practice is a little more subtle:
>int <= long[=32] < long long [=64].  most older programs tended
>to use int for things such as for loop values, that probably needed to be
>at least 16 bits, but might not need to be as much as 32.
>by contrast, a `long' quite often needed to be 32 bits, and often
>that was `no more, no less'.
>
>  
>
I'll probably regret this, but the gcc x86_64 approach hasn't worked out 
too badly.
When we did our 64 bit port recently, it was only cases of trying to 
stash a pointer
in an int which bit us. When I say us, I mean the authors of certain
Linux packages. At one time I thought there was a maxim of "int is the 
efficient
machine size, long is big enough to hold a pointer", so gcc x86_64 can 
claim to
meet that reasoning.

Nigel

Re: [9fans] Sleep-complexity

[Charles Forsyth]

i'd suspect that the gcc 64-bit long forces more changes than the other approach,
because i tried both with plan 9, and subsequently looked at a fair bit of non-plan9 code.

in fact, i tried x86_64's approach first for just the reason given:
code that fiddles with pointers as ints (in plan 9) often uses ulong,
though not invariably so, and having long as 64 bits keeps that code working.

as it turns out, relatively few things these days--certainly in plan 9--
fiddle with pointers as integers (directly, that is, not say through varargs).
those can be found by the compiler (as gcc does with pointer -> int on amd64).
by contrast, it's very hard for a compiler to find, reliably, instances
where long is assumed to be 32 bits.  bitmasks, loop bounds, ...
there are surprisingly many, things break weirdly, often obscurely,
or just on boundary cases, and having found myself in a world of pain...
i changed my mind.  all is relative sweetness and light.
at least the compiler moans instead of me.

non-plan9 code might go a little better because most of (say) the FSF
code probably assumes int is 32, so programmers typically
put the subtle 32-bit assumptions on `int', not `long'.
thus when long changes, it's less troublesome.
even so, quite a few do use long in contexts where 64-bits is not particularly useful,
probably not intended, and 32 bits would be a better representation.

Re: [9fans] Sleep-complexity

[boyd, rounin]

>> because long and int are the same so it really doesn't matter.
> 
>That's not a terribly great assumption to make, is it?

no.

as for the alpha:  i tried to argue with CRL about their
appalling choice integral type sizes, to no avail.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Sleep-complexity

[jmk]

On Tue May 10 13:10:50 EDT 2005, boyd@insultant.net wrote:
> >> because long and int are the same so it really doesn't matter.
> > 
> >That's not a terribly great assumption to make, is it?
> 
> no.
> 
> as for the alpha:  i tried to argue with CRL about their
> appalling choice integral type sizes, to no avail.
> --
> MGRS 31U DQ 52572 12604

what was their choice?

Re: [9fans] Sleep-complexity

[boyd, rounin]

> what was their choice?

long == 64 bits
int == 32 bits
short == 16 bits

i argued:

long == 32 bits
int == 64 bits
short == 16 bits

based on 'int' being a machine word.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Sleep-complexity

[rog]

> i argued:
> 
> long == 32 bits
> int == 64 bits
> short == 16 bits
> 
> based on 'int' being a machine word.

ha ha ha!

Re: [9fans] Sleep-complexity

[Ronald G. Minnich]

On Tue, 10 May 2005, boyd, rounin wrote:

> > what was their choice?
> 
> long == 64 bits
> int == 32 bits
> short == 16 bits
> 
> i argued:
> 
> long == 32 bits
> int == 64 bits
> short == 16 bits

IIRC that is what SGI did, correct? 

ron

Re: [9fans] Sleep-complexity

[David Leimbach]

On 5/10/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Tue, 10 May 2005, boyd, rounin wrote:
> 
> > > what was their choice?
> >
> > long == 64 bits
> > int == 32 bits
> > short == 16 bits
> >
> > i argued:
> >
> > long == 32 bits
> > int == 64 bits
> > short == 16 bits
> 
> IIRC that is what SGI did, correct?
> 

That would violate the C standard.

sizeof (short) <= sizeof(int) <= sizeof(long) <= sizeof(long long).

I doubt anyone did this.

> ron
>

Re: [9fans] Sleep-complexity

[Bruce Ellis]

some standards/people need to be violated - with extreme prejudice.

brucee

On 5/11/05, David Leimbach <leimy2k@gmail.com> wrote:
> On 5/10/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> >
> >
> > On Tue, 10 May 2005, boyd, rounin wrote:
> >
> > > > what was their choice?
> > >
> > > long == 64 bits
> > > int == 32 bits
> > > short == 16 bits
> > >
> > > i argued:
> > >
> > > long == 32 bits
> > > int == 64 bits
> > > short == 16 bits
> >
> > IIRC that is what SGI did, correct?
> >
> 
> That would violate the C standard.
> 
> sizeof (short) <= sizeof(int) <= sizeof(long) <= sizeof(long long).
> 
> I doubt anyone did this.
> 
> > ron
> >
>