Re: [9fans] Non-stack-based calling conventions

[Bruce Ellis]

No, the number one barrier is those who answer nearly every
thread - with misinformation, usually along the lines of  "I don't
know what I'm talking about but I'll post anyway".

I rarely post and filter me out if you like.

To answer Pietro ... Yes, Dis to assembly is common.  That's
what the JITs are - they are fun and instructive to write.  Yes,
there was a good C interpreter back in 10th edition days.  I was
one of the authors.  It is still on my micro-vax.

To answer Uriel ... I believe shand may have a copy of boyd's stuff.

As for Linus, I'm sure he's a nice guy.  I'm quite happy with my
own life thanks.

brucee

On Feb 18, 2008 5:22 PM, Robert William Fuller
<[EMAIL PROTECTED]> wrote:
> Bruce Ellis wrote:
> > how did this get past my erik filter?
> >
> > wrong, wrong, wrong, wrong.
> >
> > four out of four as expected.
>
> Erik,
>
> Don't let the bastards get you down.  Believe me when I say you're not
> the only one who would vote Bruce off the list if it were an option.
>
> The number one barrier to the advancement of Plan9 is some of the
> louder, more unsavory personalities surrounding the project.  9fans
> seems to be frequented by more than a few jealous, wanna-be Linus's.
> They are the project's greatest liability.
>
> Regards,
>
> Rob
>

Re: [9fans] Non-stack-based calling conventions

[Robert William Fuller]

Bruce Ellis wrote:

how did this get past my erik filter?

wrong, wrong, wrong, wrong.

four out of four as expected.


Erik,

Don't let the bastards get you down.  Believe me when I say you're not 
the only one who would vote Bruce off the list if it were an option.


The number one barrier to the advancement of Plan9 is some of the 
louder, more unsavory personalities surrounding the project.  9fans 
seems to be frequented by more than a few jealous, wanna-be Linus's. 
They are the project's greatest liability.


Regards,

Rob

[9fans] Insultant...

[Uriel]

.net and boydo.net are gone, anyone knows where to find a mirror of
boyd's stuff? I somene can find I copy I will try to host it. (A
source more convenient than archive.org would be appreciated,
specially if it includes full blog archives).

uriel

Re: [9fans] Non-stack-based calling conventions

[Uriel]

Time to reach for the 92FS...

Dear pietro, if you don't even know that the Plan 9 toolchain *is*
ken's toolchain, and your other comments are totally irrelevant, why
don't you just shut the fuck up?

And this obviously doesn't mean erik was right, brucee as usual hit
every nail straight in the head.

uriel - trying to do a boyd

On Feb 18, 2008 5:46 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
>
> And if you're going to rebut and say that limbo needs dis, then check this
> out:
>
> /n/sources/contrib/andrey/dis.tar.gz (or something)
>
> Also works with the Plan 9 toolchain, but you may need to change some files
> now.
>
>
>
> On Feb 17, 2008, at 11:44 PM, Pietro Gagliardi wrote:
>
> One more thing:
>
> On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote:
>
> porting limbo to a new architecture requires porting ken's toolchain
> and the inferno kernel.
>
> /n/sources/contrib/pietro/limbo.tgz
>
> The only thing ported was the source code and mkfiles.
>
>
>

Re: [9fans] ld.com

[lucio]

> ld.com should be tossed away.  you're supposed to use 9load these days,
> which doesn't have those limitations.

Maybe, but at the time I hoped that ld.com would allow me to overcome
a problem with formatting a Compact Flash card I kept getting wrong (I
have got it right eventually, now I need to document how) and secondly
it doesn't help to have documentation that conflicts with reality.  I
think it is a privilege other OSes can't afford to be able to say in
the documentation "Ld.com has grown beyond 64K and therefore can no
longer be used, but it may be possible to strip it further, feel free
to contribute fixes".

That said, I have managed to get 9load into place in a 9FAT partition,
but now I cannot run 9pc.gz kernels newer than
/n/sourcesdump/2005/1106/plan9/386/9pc.gz on the SiS 550 processor.
I'm not sure what broke, but of course some of the guesswork:

term% grep -n SiS /n/sourcesdump/2005/1110/plan9/sys/src/9/pc/devarch.c
619:  * SiS 55x
623:{5, 0,  23, "SiS 55x",},/* guesswork */
678:else if(strncmp(m->cpuidid, "SiS SiS SiS ", 12) == 0)

may be at fault.  Suggestions welcome.

++L

Re: [9fans] Non-stack-based calling conventions

[Pietro Gagliardi]

And if you're going to rebut and say that limbo needs dis, then check  
this out:


/n/sources/contrib/andrey/dis.tar.gz (or something)

Also works with the Plan 9 toolchain, but you may need to change some  
files now.


On Feb 17, 2008, at 11:44 PM, Pietro Gagliardi wrote:


One more thing:

On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote:


porting limbo to a new architecture requires porting ken's toolchain
and the inferno kernel.


/n/sources/contrib/pietro/limbo.tgz

The only thing ported was the source code and mkfiles.

Re: [9fans] Non-stack-based calling conventions

[Pietro Gagliardi]

One more thing:

On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote:


porting limbo to a new architecture requires porting ken's toolchain
and the inferno kernel.


/n/sources/contrib/pietro/limbo.tgz

The only thing ported was the source code and mkfiles.

Re: [9fans] Non-stack-based calling conventions

[Pietro Gagliardi]

New question: can Limbo be compiled to raw binary to run on native  
hardware? Yes. Will I do it? No.


Next question: can C be interpreted like Limbo? Yes. (10th edition  
Unix has such a program.) Will I do it? No.


Someone's ideas on a programming language should not be "forced" onto  
another's state of mind. I don't like some of the features of Limbo  
(sys := load Sys Sys->PATH) and I don't think Limbo can be used to  
write a system kernel without an abundant amount of reductions or  
compiler hacks (http://www.osdev.org/wiki/C_PlusPlus discusses enough  
of them for C++ to make one puke). If someone defies those odds, good  
for them. Also, C can be a pain in the neck at so many times (pointer  
arithmetic multiplies the difficulty of porting Assembly to C). C can  
be made to type-check at runtime, but will I do it to C itself? Not  
when I'm porting about 30 Assembly files to C. I fear I've fallen  
victim to the complications of Duff's device and the alt construct,  
so I'll stop.


Flame extinguished.

On Feb 17, 2008, at 11:31 PM, Bruce Ellis wrote:


you've changed your claims!

it says elephant!

1) no, limbo is not good for everything. my doorbell is better  
without it.

in the context of the original thread you just dismissed it because
you wanted to argue.

2) porting limbo does not require ken's tool chain. have you had
experience with this? anything "self-containted" can only blame
itself for its blemishes.

3) the performance gain of having a fixed tlb with no context switch
penalty is amazing. have you had experience with this?

4) if you are hacking the kernel then you aren't hacking limbo so
what is the point of #4.

after 41 messages in this thread you'll ask for references.

brucee

On Feb 18, 2008 2:43 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:

how did this get past my erik filter?

wrong, wrong, wrong, wrong.

four out of four as expected.

brucee


100% whinage.  0 justification.   0 information.  par for the  
course. ☺


since you disagree, i assume you claim that limbo's the hammer and  
all

computing problems are nails.  i'd like to know why limbo's the right
thing to run, e.g., on a freescale hc08 microcontroller.  i'd also  
like to know

why there is no performance penalty for running dis code over c.  do
you claim the garbage collection doesn't take any appreciable time?
and the there is no overhead dealing with limbo's runtime  
typechecking?
the inferno kernel i know about is written in c.  where's the  
limbo version?
how does one run a limbo program on a new architecture without  
porting

the runtime or jit?

- erik

Re: [9fans] Non-stack-based calling conventions

[Bruce Ellis]

you've changed your claims!

it says elephant!

1) no, limbo is not good for everything. my doorbell is better without it.
in the context of the original thread you just dismissed it because
you wanted to argue.

2) porting limbo does not require ken's tool chain. have you had
experience with this? anything "self-containted" can only blame
itself for its blemishes.

3) the performance gain of having a fixed tlb with no context switch
penalty is amazing. have you had experience with this?

4) if you are hacking the kernel then you aren't hacking limbo so
what is the point of #4.

after 41 messages in this thread you'll ask for references.

brucee

On Feb 18, 2008 2:43 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> > how did this get past my erik filter?
> >
> > wrong, wrong, wrong, wrong.
> >
> > four out of four as expected.
> >
> > brucee
>
> 100% whinage.  0 justification.   0 information.  par for the course. ☺
>
> since you disagree, i assume you claim that limbo's the hammer and all
> computing problems are nails.  i'd like to know why limbo's the right
> thing to run, e.g., on a freescale hc08 microcontroller.  i'd also like to 
> know
> why there is no performance penalty for running dis code over c.  do
> you claim the garbage collection doesn't take any appreciable time?
> and the there is no overhead dealing with limbo's runtime typechecking?
> the inferno kernel i know about is written in c.  where's the limbo version?
> how does one run a limbo program on a new architecture without porting
> the runtime or jit?
>
> - erik
>
>

Re: [9fans] Non-stack-based calling conventions

[erik quanstrom]

> how did this get past my erik filter?
> 
> wrong, wrong, wrong, wrong.
> 
> four out of four as expected.
> 
> brucee

100% whinage.  0 justification.   0 information.  par for the course. ☺

since you disagree, i assume you claim that limbo's the hammer and all
computing problems are nails.  i'd like to know why limbo's the right
thing to run, e.g., on a freescale hc08 microcontroller.  i'd also like to know
why there is no performance penalty for running dis code over c.  do
you claim the garbage collection doesn't take any appreciable time?
and the there is no overhead dealing with limbo's runtime typechecking?
the inferno kernel i know about is written in c.  where's the limbo version?
how does one run a limbo program on a new architecture without porting
the runtime or jit?

- erik

Re: [9fans] ld.com

[Russ Cox]

> According to the manual, ld.com is a stripped down version of 9load,
> intended to fit in 64KB.  It doesn't, my "production" version is:
> which seems to be the current version.  Any suggestions?  I don't
> really want to rebuild it unnecessarily.

ld.com should be tossed away.  you're supposed to use 9load these days,
which doesn't have those limitations.

russ

Re: [9fans] Non-stack-based calling conventions

[Bruce Ellis]

how did this get past my erik filter?

wrong, wrong, wrong, wrong.

four out of four as expected.

brucee

On Feb 18, 2008 10:58 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> >> so if you're running without the operating system or your application
> >> is the operating system (embedded systems), virtual memory might
> >> just get in the way.  tlb hardware doesn't do its translation for free.
> >
> > Or if you have moved onto the greener pastures of Limbo... not having
> > to worry about all this saves many headaches when you want to port
> > Inferno to a new arch too.
> >
> > uriel
>
> the world isn't this simple.  just cause you've got the limbo hammer, doesn't
> mean all the world's a nail.
>
> porting limbo to a new architecture requires porting ken's toolchain
> and the inferno kernel.  i don't see how a self-containted operating system/
> application would be less work to port.
>
> if the work you're doing is performance-sensitive enough that tlb misses
> make a difference, then you certainly do not want to pay the penalty of
> a virtual machine.
>
> further, if the work you're doing is in the kernel or kernel-level, unless you
> have hardware implemting dis, you can't write this in a language like limbo
> which targets a virtual machine.
>
> - erik
>
>

Re: [9fans] Non-stack-based calling conventions

[erik quanstrom]

>> so if you're running without the operating system or your application
>> is the operating system (embedded systems), virtual memory might
>> just get in the way.  tlb hardware doesn't do its translation for free.
> 
> Or if you have moved onto the greener pastures of Limbo... not having
> to worry about all this saves many headaches when you want to port
> Inferno to a new arch too.
> 
> uriel

the world isn't this simple.  just cause you've got the limbo hammer, doesn't
mean all the world's a nail.

porting limbo to a new architecture requires porting ken's toolchain
and the inferno kernel.  i don't see how a self-containted operating system/
application would be less work to port.

if the work you're doing is performance-sensitive enough that tlb misses
make a difference, then you certainly do not want to pay the penalty of
a virtual machine.

further, if the work you're doing is in the kernel or kernel-level, unless you
have hardware implemting dis, you can't write this in a language like limbo
which targets a virtual machine.

- erik

Re: [9fans] Non-stack-based calling conventions

[Chad Dougherty]

Lluís Batlle wrote:

Maybe someone in this list can provide a good example of coroutines use?



I found Russ's recent post about Duff's device and the PuTTY coroutine 
example that it referenced interesting:




-Chad

Re: [9fans] Non-stack-based calling conventions

[Charles Forsyth]

>> do Plan 9 compilers output COFF object files?
> 

never.  ken thompson's paper tells enough, if not all.

Re: [9fans] Non-stack-based calling conventions

[Uriel]

> so if you're running without the operating system or your application
> is the operating system (embedded systems), virtual memory might
> just get in the way.  tlb hardware doesn't do its translation for free.

Or if you have moved onto the greener pastures of Limbo... not having
to worry about all this saves many headaches when you want to port
Inferno to a new arch too.

uriel

[9fans] Plan 9 featured in virtualizer review

[Pietro Gagliardi]

http://www.thinkmac.net/review/review-q-free-virtualizer

A review I wrote of Q, the open-source QEMU front-end for Mac OS X.  
The first screenshot contains games/sudoku and proof showing the  
words "Plan 9 from Bell Labs" in Lucida Sans.


Sorry for the noise.

Re: [9fans] Non-stack-based calling conventions

[Anthony Sorace]

On 2/17/08, Eris Discordia <[EMAIL PROTECTED]> wrote:

> do Plan 9 compilers output COFF object files?

not typically, but some of the linkers can be instructed to. see the
-Hn argument in 2l(1). the list of what the linkers can generate isn't
documented, but look for HEADTYPE in /sys/src/cmd/[12578kqv]l/obj.c. i
haven't had a machine to try the output on in several years, but vl's
documented ability to produce IRIX coff executables at least used to
work.

Re: [9fans] Non-stack-based calling conventions

[erik quanstrom]

> COFF has had to cope with a certain monster dubbed portability; to adapt  
> to the peculiarities of the many flavors of UNIX (and at least one  
> Microsoft OS, with MS-COFF). So good it has been practically put out of  
> business by ELF or... do Plan 9 compilers output COFF object files?

see a.out(6).

> COFF has had to cope with a certain monster dubbed portability; to adapt  
> to the peculiarities of the many flavors of UNIX (and at least one  
> Microsoft OS, with MS-COFF). So good it has been practically put out of  
> business by ELF or... do Plan 9 compilers output COFF object files?

flat memory model:
http://en.wikipedia.org/wiki/CDC_6600#Memory_organization

> I am actually very grateful for having a flat 32/64 bit address space all  
> to myself. Even though the curse of managing virtual memory and driving  
> the associated hardware has been placed on every OS developer, occasional  
> programmers like me really enjoy the outcome.

it's interesting to note that it is being loaded at a constant address
makes the job of loading & generating the code much simplier.  the
location of allocated memory isn't as important --- those details
can often be hidden in an malloc-style function.  even on 386
hardware, segments can be used to cover all of memory.  as long
as your allocator knows where not to step (pci space, for example),
this should be good enough.

so if you're running without the operating system or your application
is the operating system (embedded systems), virtual memory might
just get in the way.  tlb hardware doesn't do its translation for free.

- erik

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Eric Van Hensbergen]

On Feb 17, 2008 1:01 AM, Steve Simon <[EMAIL PROTECTED]> wrote:
> there was somthing which analysed C and produced a call graph in the form
> of input for dot(1) years ago, the problem was a complex program produced a
> complex graph... I will try to find out the packages name if required, I have
> a feeling it may have been in comp.sources.(unix misc).
>

Doxygen does this (and data-structure graphs as well) - I'm not sure
if its a component which could be easily extracted or not.
Actually, I just did this to look at the data-structures and
call-graphs for v9fs (http://www.kernel.org/~ericvh/doxygen)

-eric

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Anthony Sorace]

someone on irc pointed out nemo's tools when i was most of the way
through getting ctags to work. they do look interesting, the tagfs
thing particularly. i continued with ctags because it's cross-platform
(i do much of my programming with acme on OS X) and has a good range
of languages (nemo's man page talks about several languages, but i
could only find the tagger for C).

Re: [9fans] Non-stack-based calling conventions

[Eris Discordia]

On Sun, 17 Feb 2008 00:04:31 -, Brantley Coile <[EMAIL PROTECTED]>  
wrote:



The relocation formats for the 6600 assembler wasn't that complicated,
much less than coff.  For the Cyber 17/18 the instructions could
be pc relative and didn't have to be relocated when linked together,
at least not for the call/return scenario.


I remember the necessity of relocation was not limited to where you had to  
link binaries. On the 80286 + MS-DOS combination, lack of virtual memory  
hardware (the "real" mode) made relocation inevitable as processes were  
not isolated and memory was not multiplexed by the hardware and/or OS.  
Without a flat and isolated address space for each process, every  
executable had to adjust to where it was being loaded. Hence, the EXE  
header and relocation table.


COFF has had to cope with a certain monster dubbed portability; to adapt  
to the peculiarities of the many flavors of UNIX (and at least one  
Microsoft OS, with MS-COFF). So good it has been practically put out of  
business by ELF or... do Plan 9 compilers output COFF object files?



The 6600 had a field address that was added to the program counter
to relocate the program.  It also had a field length register to
make sure you didn't spill off the end.


No far jumps/calls? Was the memory model not segmented?


All was much simpler than today.


I am actually very grateful for having a flat 32/64 bit address space all  
to myself. Even though the curse of managing virtual memory and driving  
the associated hardware has been placed on every OS developer, occasional  
programmers like me really enjoy the outcome.


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/