Re: [9fans] Stack initialisation

Re: [9fans] Stack initialisation

[lucio]

> By the way, it took me just a couple of hours each to convert
> Rio and Acme from Alef to the new threaded C. It's not hard to
> do.

Granted.  And practice would be the right way to learn.  Please don't
take it as stubborness, I have a Limbo program I want to port to Plan
9 (I'm still saving up for the Inferno distribution, US$300 is quite a
lot of money down here) and I was wondering how difficult it would be
to get Alef up and running.

I accept that portability is critical, and that Bell Labs' efforts to
provide a C thread library should not be dismissed lightly.  On the
other hand, there's room for taste, and I hope I'm not the only one to
believe that the elegance of Alef should not be entirely sacrificed on
the altar of pragmatism.

With a bit of luck, there will be a community (are you listening,
Charles?)  of interested parties willing to put in some effort and
supplement Bell Labs' offering with some of our own.

It is easy enough for Bell Labs to point out that use of Alef is not
supported and is deprecated.

++L

Re: [9fans] Stack initialisation

[ozan s. yigit]

lucio@proxima.alt.za writes:

> I accept that portability is critical, and that Bell Labs' efforts to
> provide a C thread library should not be dismissed lightly.  On the
> other hand, there's room for taste, and I hope I'm not the only one to
> believe that the elegance of Alef should not be entirely sacrificed on
> the altar of pragmatism.

looks like existing compiler cannot be distributed outside 2nd edition
licensees. are you going to reimplement alef? if you are going to spend
the time, why not re-implement limbo? at least that is a language
with some future use under other OSs as well.

alef is an island, elegant or not.

oz

Re: [9fans] Stack initialisation

[Lucio De Re]

On Wed, Aug 30, 2000 at 03:36:55PM +0000, ozan s. yigit wrote:
> 
> looks like existing compiler cannot be distributed outside 2nd edition
> licensees. are you going to reimplement alef? if you are going to spend
> the time, why not re-implement limbo? at least that is a language
> with some future use under other OSs as well.
> 
I'm hoping you're wrong, but I take your point.

I'm really not competent enough to re-implement Limbo _or_ Alef,
although I'm pretty certain a re-implementation would produce a
language with the best features from both.  They are really not that
distinct, to my ability to determine this.

> alef is an island, elegant or not.
> 
Maybe.  But it is also a proof of principle, and it has a following.
If Plan 9 is to fly from the Bell Labs nest, Alef may be part of the
wind beneath its wings.  But please keep in mind that I do not have a
religious need to move in the Alef direction, I just happen to like
the language and the challenge to make it work.  My own abilities in
this matter are limited.

++L

Re: [9fans] Stack initialisation

[Boyd Roberts]

i'd chuck my hand in with limbo.  my first limbo module:

    http://www.planete.net/~boyd/code/pop.bundle

[a pop3 client] took about 3 hours to write, with a few beers
and a bit of coaching from brucee.

i was amazed.  garbage collected fd's -- wow...

i think a small amount of 'worms' was played at the same time.

the original, written in C, took several days (excluding a night
in a pub in york designing it and thinking up a method to minimise
the password winding up in a core dump -- taunton dry blackthorn
cider was required).

Re: [9fans] Stack initialisation

[Lucio De Re]

On Wed, Aug 30, 2000 at 06:32:13PM +0200, Boyd Roberts wrote:
> 
> i'd chuck my hand in with limbo.  my first limbo module:
> 
>     http://www.planete.net/~boyd/code/pop.bundle
> 
> [a pop3 client] took about 3 hours to write, with a few beers
> and a bit of coaching from brucee.
> 
Yes, Limbo is surprisingly easy.  And effective.  Took me a long time
to figure out how to time out on a read(), though (the CD-ROM released
version didn't include the timed read function).

> i was amazed.  garbage collected fd's -- wow...
> 
That's a runtime feature.  No reason why the gems in Limbo cannot be
adopted elsewhere.  And Limbo is at its best within the Inferno system.
I would be perfectly happy with a port to Plan 9, but I don't hear
many offers.  Plus, Charles is hopefully going to make a
(comfortable?) living out of Inferno and Limbo (hm, where's Paradiso?)
and we may want to help him by keeping Inferno and Plan 9 distinct.

> the original, written in C, took several days (excluding a night
> in a pub in york designing it and thinking up a method to minimise
> the password winding up in a core dump -- taunton dry blackthorn
> cider was required).
> 
No point in asking if the Alef version would have been any easier?  No
matter, let's get the most out of the tools we have, and try to keep
religious wars right out of the picture.

Plus, there are graphics to do, that's a hell of a lot of work, if I'm
not mistaken.

++L

Re: [9fans] Stack initialisation

[Boyd Roberts]

From: Lucio De Re <lucio@proxima.alt.za>
> > 
> No point in asking if the Alef version would have been any easier?

i can't comment on alef, except i never really liked it.
IIRC acme was written in alef?  interesting, but not for me.

as soon as i saw limbo i was sold.

gee, and i haven't 'done a boyd' yet.  maybe i'm building up to it :-)

Re: [9fans] Stack initialisation

[Lucio De Re]

On Wed, Aug 30, 2000 at 06:59:57PM +0200, Boyd Roberts wrote:
> 
> i can't comment on alef, except i never really liked it.
> IIRC acme was written in alef?  interesting, but not for me.
> 
Surprising.

> as soon as i saw limbo i was sold.
> 
Not surprising.

> gee, and i haven't 'done a boyd' yet.  maybe i'm building up to it :-)
> 
What you mean?!  Not being able to see the similarities between Limbo
and Alef isn't having "done a boyd"?!  :-)  :-)  :-)

(Bent diodes are permissible in this mailing list, aren't they?)

++L

Re: [9fans] Stack initialisation

[Elliott Hughes]

"Lucio De Re" <lucio@proxima.alt.za> wrote in message
news:20000830184427.F3753@cackle.proxima.alt.za...
> ...  Inferno and Limbo (hm, where's Paradiso?)

Limbo isn't the same as purgatorio, and Paradiso is just outside Bellinzona,
Switzerland. There are many other places called Paradiso in Italy, but the
Swiss one was the first I ever saw. It's OK, there's even a McDonald's
nearby.

- Elliott

Re: [9fans] Stack initialisation

[lucio]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

In Elliott Hughes' words:
> 
> Limbo isn't the same as purgatorio, and Paradiso is just outside
> Bellinzona, Switzerland.  There are many other places called
> Paradiso in Italy, but the Swiss one was the first I ever saw.
> It's OK, there's even a McDonald's nearby.
> 
Touché.  And to think that I actually plodded through the first two
books of the Divina Commedia.  I stand corrected.

++L


[-- Attachment #2: Type: message/rfc822, Size: 2327 bytes --]

From: Elliott Hughes <elliott.hughes@genedata.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Stack initialisation
Date: Thu, 31 Aug 2000 09:26:10 GMT
Message-ID: <39ae17fa@news.core.genedata.com>

"Lucio De Re" <lucio@proxima.alt.za> wrote in message
news:20000830184427.F3753@cackle.proxima.alt.za...
> ...  Inferno and Limbo (hm, where's Paradiso?)

Limbo isn't the same as purgatorio, and Paradiso is just outside Bellinzona,
Switzerland. There are many other places called Paradiso in Italy, but the
Swiss one was the first I ever saw. It's OK, there's even a McDonald's
nearby.

- Elliott

Re: [9fans] Stack initialisation

[okamoto]

>> alef is an island, elegant or not.
>> 
>Maybe.  But it is also a proof of principle, and it has a following.

I completely agree with your concept.
In Plan 9, every real world's restriction should be kicked out! ☺

Kenji

Re: [9fans] Stack initialisation

[forsyth]

>>the password winding up in a core dump -- taunton dry blackthorn
>>cider was required).

presumably IMAP4 would have required old peculier or owd roger

Re: [9fans] Stack initialisation

[Boyd Roberts]

From: <forsyth@vitanuova.com>

> >>the password winding up in a core dump -- taunton dry blackthorn
> >>cider was required).
> 
> presumably IMAP4 would have required old peculier or owd roger

maybe a 9mm automatic :-)  i have a bad feeling about IMAP.

Re: [9fans] Stack initialisation

[lucio]

Charles Forsyth says:
> on the other hand, if you or someone else is still keen, i can
> contribute the powerpc Alef port i did a few years ago for the
> 2nd edition.  i did it mainly to have Acme on the powerpc.
> 
I'd appreciate that.  I'll only be able to play some sort of
coordination role (a private CVS repository?)  as I have no access to
hardware other than scrappy Intel boxes (not even a multiprocessor :-(

But I'll be very pleased if something like Alef makes Plan 9 stand out
in the crowd of Unix look-alikes.

++L

Re: [9fans] Stack initialisation

[forsyth]

>>With a bit of luck, there will be a community (are you listening,
>>Charles?)  of interested parties willing to put in some effort and
>>supplement Bell Labs' offering with some of our own.

yes, although I'm busy enough not to want to support Alef as well.
i'm not sure I would do so if I had the time.  I had only a few Alef
programs and I converted one set to C <thread.h> and the
other set to Limbo.

on the other hand, if you or someone else is still keen, i can contribute
the powerpc Alef port i did a few years ago for the 2nd edition.
i did it mainly to have Acme on the powerpc.

the use of a different calling sequence contributes to the nuisance
of maintaining Alef, because all the libraries need to be converted
(and in fact was not done completely last time).  sometimes that's good,
when they weren't previously thread-safe, but often it's just a nuisance
and a headache for maintenance.

Re: [9fans] Stack initialisation

[rob pike]

By the way, it took me just a couple of hours each to convert Rio and Acme
from Alef to the new threaded C.   It's not hard to do.

-rob

Re: [9fans] Stack initialisation

[rob pike]

We didn't include Alef with the 3rd edition because it introduces
a portability issue: it requires maintenance of a second compiler
and set of libraries.  We only had an Alef compiler for the 386,
Mips, and Sparc, only two of which are current kernel architectures.
We don't have an Alef compiler for the Alpha, Power PC, or ARM,
which are.  Rather than port the compiler and libraries, we decided
to port the few Alef applications back to C.  Otherwise, getting a
new architecture running is just too much work.

So I congratulate you on getting Alef running on the 386 again, but
remind you that it wasn't included in the second edition for a reason.
We're not going to be enthusiastic about redistributing Alef again
unless someone is willing to do the other ports, and even that's
probably not reason enough.  Of course, you're free to redistribute
it yourself to 2nd edition licensees, who are the only people likely
to have old Alef programs lying around anyway.

Sorry, guys, but it's not quite a pure PC world, at least not yet.

-rob

Re: [9fans] Stack initialisation

[okamoto]

>Without a doubt.  You're a holder of a 2ed licence, so I see no
Don't doubt me, Lucio, please!  I have its licence for my Univ.☺

You may deliver me from the restriction of two file servers, 2ed and 3ed.
It may save the wasteful power consumption of our Univ.  ☺

Kenji

Re: [9fans] Stack initialisation

[Lucio De Re]

On Wed, Aug 30, 2000 at 03:14:03PM +0000, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> 
> >Without a doubt.  You're a holder of a 2ed licence, so I see no
> Don't doubt me, Lucio, please!  I have its licence for my Univ.?
> 
Surely :-)

> You may deliver me from the restriction of two file servers, 2ed and 3ed.
> It may save the wasteful power consumption of our Univ.  ?
> 
But don't be too hasty.  I just got the thing running, you're going to
be the one who's going to prove it's doing its job properly :-)

++L

Re: [9fans] Stack initialisation

[okamoto]

>and now I have
>a version of Alef for 3rd Edition Plan 9 that (apparently) compiles
>and executes programs on my i386 PC. 

Wao!
I'm now in trouble to bring a Alef program (not graphics) to 3ed
C thread version. (sigh)

Can I see your change, Lucio?

Kenji

Re: [9fans] Stack initialisation

[Lucio De Re]

On Wed, Aug 30, 2000 at 02:44:32PM +0000, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> 
> Wao!
> I'm now in trouble to bring a Alef program (not graphics) to 3ed
> C thread version. (sigh)
> 
> Can I see your change, Lucio?
> 
Without a doubt.  You're a holder of a 2ed licence, so I see no
difficulty whatever.  It's easiest if I just bundle up (tar and gzip)
the /sys/src/alef directory as I have it, and you can just follow my
few additional instructions with a pinch of salt.

I'll mail you the lot as soon as I have it all in place unless I hear
something to the contrary from you (or the Labs, I suppose, but
there's no one there :-).

++L

Re: [9fans] Stack initialisation

[forsyth]

>>	Ptab    = 0xbfff5000,    /* Private stack */
>>	Execstk = 0xbf001000,    /* Exec stack linkage area */

the values are related to those of USTKTOP and USTKSIZE
in the  2nd edition kernel, both of which differ in the 3rd edition
kernel, since the arrangement of virtual memory has changed slightly
(on the PC at least).
the exec stack grabs addresses at the low end of the virtual memory
region reserved for the stack, presumably on the grounds that most
Alef processes haven't used the full 16 megabytes.  it is
space that will be reclaimed automatically after the exec.
that's from memory of doing the Alef port to the powerpc
and looking at the various definitions.

Re: [9fans] Stack initialisation

[Lucio De Re]

On Tue, Aug 29, 2000 at 11:08:51PM +0000, forsyth@vitanuova.com wrote:
> 
> >>	Ptab    = 0xbfff5000,    /* Private stack */
> >>	Execstk = 0xbf001000,    /* Exec stack linkage area */
> 
> the values are related to those of USTKTOP and USTKSIZE
> in the  2nd edition kernel, both of which differ in the 3rd edition
> kernel, since the arrangement of virtual memory has changed slightly
> (on the PC at least).

Well, to reveal the truth, the new values (that work, that is, I think
I can tweak them further) are

	Ptab     = 0x7fff5000,  (could possibly be 0x7fffe000)
	Execstk  = 0x7f001000,	(not sure about this one)

(thank you, Charles, you put me on the right track), and now I have
a version of Alef for 3rd Edition Plan 9 that (apparently) compiles
and executes programs on my i386 PC.  Anyone got something easier than
the test/ programs.  I tried sieve, pstest and tstbio with seeming
success, I'm not sure what test should produce and I have not tried
anything else.

I haven't yet tackled the graphic libraries (libg.a and libframe.a), I
suspect I won't get that right alone, but I'll give it a good try.
Only too happy to feed back the changed sources to Bell Labs, and do
whatever necessary to keep them current.

I have no idea what other changes to the 2ed libraries I may have
neglected, and so on; feel free to push me in the right direction.

++L

Re: [9fans] Stack initialisation

[rob pike]

Are you referring to the local stack?  Each true process (proc) has a
private stack, so it's possible to do things like place a pointer in high
memory that points to memory unique to that process, a storage class
that's hard to get in fully shared memory.

-rob

Re: [9fans] Stack initialisation

[rob pike]

Are you referring to the local stack?  Each true process (proc) has a
private stack, so it's possible to do things like place a pointer in high
memory that points to memory unique to that process, a storage class
that's hard to get in fully shared memory.

-rob

Re: [9fans] Stack initialisation

[Lucio De Re]

On Tue, Aug 29, 2000 at 12:45:20PM -0400, rob pike wrote:
> 
> Are you referring to the local stack?  Each true process (proc) has a
> private stack, so it's possible to do things like place a pointer in high
> memory that points to memory unique to that process, a storage class
> that's hard to get in fully shared memory.
> 
The exact details I don't understand (for i386 - from
/sys/src/alef/lib/386/run.h):

enum
{
	Ptab    = 0xbfff5000,    /* Private stack */
	Execstk = 0xbf001000,    /* Exec stack linkage area */
};

what I would like explained is how these are allocated, or more
appropriately, where does the process get granted permission to use
what seem like two arbitrary areas of memory?

Please keep in mind that I am not up to date with "recent" OS and
architecture developments and memory allocation and virtual memory
are still black magic to me.  Finding the details by searching
through the kernel sources would be very tedious and probably I'd
miss the wood for the trees.

In this particular instance, it may suffice for me to find out whether
in 3rd edition Plan 9 these values are different and what they are,
but actually knowing how they are established would make me a lot
happier.  Of course, if they are arbitrary, then I'll never find out
why reusing code containing the above fails when assigning to an
entity in that area :-(

Thanks for any assistance.

++L

[9fans] Stack initialisation

[Lucio De Re]

In 2nd Edition Plan 9, Alef allocated some private memory in what
seems like arbitrary locations on the i386, Mips and Sparc
architectures.

I can't find either an equivalent private allocation for the C
compiler, nor a clarification as to how this works for Alef.  Can
someone explain quite how this private allocation works, how it
interacts with the underlying system?  Specially if it is different
in 3rd Edition Plan 9?

Thanks.

++L