[9fans] Non-stack-based calling conventions

[9fans] Non-stack-based calling conventions

[Andrew Simmons]

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

Don't diss brucee. He's one of the few reasons for still keeping a
tenth of an eye on the list. These days I even miss Choate. "Let he
without stone cast the first stone" was pure genius. Most of all I
miss the benign presence of Presotto, forever attempting to pour oil
on troubled waters.

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

[Brantley Coile]

>>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.
>
> Don't diss brucee. He's one of the few reasons for still keeping a
> tenth of an eye on the list. These days I even miss Choate. "Let he
> without stone cast the first stone" was pure genius. Most of all I
> miss the benign presence of Presotto, forever attempting to pour oil
> on troubled waters.

Small point.  The quote is `Let he who is without sin cast the first stone.'
		Johh 8:7

   And Jesus said, ``Heither do I condemn you; go; and from now on sin
   no more.''

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

[Andrew Simmons]

>
> Small point.  The quote is `Let he who is without sin cast the first stone.'
>                 Johh 8:7
>
Not in Choate's version. It's in the archives.

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

[Uriel]

While we are at it... lets remember that young people don't know any
history.  Everyone knows that the first language with garbage
collection was Visual Basic.

uriel

On Feb 19, 2008 1:43 AM, Andrew Simmons <kodogo@gmail.com> wrote:
> >
> > Small point.  The quote is `Let he who is without sin cast the first stone.'
> >                 Johh 8:7
> >
> Not in Choate's version. It's in the archives.
>

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

[Pietro Gagliardi]

On Feb 18, 2008, at 7:52 PM, Uriel wrote:

> While we are at it... lets remember that young people don't know any
> history.  Everyone knows that the first language with garbage
> collection was Visual Basic.

When, in reality, it was Lisp. Who knew?

I actually know a bit more about the Bell Labs-rooted history of the
computer than about 99% people my age.

Some more questions:
What was the first object-oriented language?
	WHAT YOU MIGHT HEAR:
		- C++
		- Java
	CORRECT:
		- Simula
What was the first high-level programming language?
	WHAT YOU MIGHT HEAR:
		- BASIC
		- Pascal
		- C
	CORRECT:
		- FORTRAN I
First microprocessor?
	WHAT YOU MIGHT HEAR:
		- 8086
		- 68000
	CORRECT:
		- 4004
Microsoft's *other* operating system, besides OS/2:
	WHAT YOU MIGHT HEAR:
		- I doubt there was one.
	CORRECT:
		- XENIX
Name the most important person/people in the computer field to date.
	WHAT YOU MIGHT HEAR:
		- Bill Gates
		- Steve Jobs
	CORRECT:
		- Thompson & Ritchie, all the way! :-)
		- Alan Turing
		- The great Structured Programming trio: Hoare, Dijkstra, and Dahl
		- Knuth
Name the computer that started it all.
	WHAT YOU MIGHT HEAR:
		- The first IBM PC
	CORRECT:
		- The DEC PDP-11
What other thing, besides Unix, was the PDP-11 famous for?
	WHAT YOU MIGHT HEAR:
		- ???
	CORRECT:
		- Tetris!

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

[Brantley Coile]

> Name the computer that started it all.
> 	WHAT YOU MIGHT HEAR:
> 		- The first IBM PC
> 	CORRECT:
> 		- The DEC PDP-11

You have a dangerous post there with so many
assertions, but I'll only point out
that the pdp-7, not the 11, started it all.
Ed Sitar had one he wasn't using anymore
that originally was connected to the mainframe and
used as a graphics terminal.

You gotta love the operate instruction.

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

[Michaelian Ennis]

On Feb 18, 2008 8:06 PM, Pietro Gagliardi <pietro10@mac.com> wrote:

> Name the most important person/people in the computer field to date.
>         WHAT YOU MIGHT HEAR:
>                 - Bill Gates
>                 - Steve Jobs
>         CORRECT:
>                 - Thompson & Ritchie, all the way! :-)
>                 - Alan Turing
>                 - The great Structured Programming trio: Hoare, Dijkstra, and Dahl
>                 - Knuth

I think Wirth, who you didn't mention would list Blaise Pascal amongst them.

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

[Michaelian Ennis]

On Feb 18, 2008 10:18 PM, Michaelian Ennis <michaelian.ennis@gmail.com> wrote:
> On Feb 18, 2008 8:06 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
>
> > Name the most important person/people in the computer field to date.
> >         WHAT YOU MIGHT HEAR:
> >                 - Bill Gates
> >                 - Steve Jobs
> >         CORRECT:
> >                 - Thompson & Ritchie, all the way! :-)
> >                 - Alan Turing
> >                 - The great Structured Programming trio: Hoare, Dijkstra, and Dahl
> >                 - Knuth

Oh and if you like using transistors for compution,  Pingala had an
interserting contribution.

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

[Pietro Gagliardi]

So there is no definite answer to that question. Perhaps even I, who
has not fully published anything well-programmed (my pico is still a
mess), could be considered this way. Both "important" and "to date"
are relative.

On Feb 18, 2008, at 10:29 PM, Michaelian Ennis wrote:

> On Feb 18, 2008 10:18 PM, Michaelian Ennis
> <michaelian.ennis@gmail.com> wrote:
>> On Feb 18, 2008 8:06 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
>>
>>> Name the most important person/people in the computer field to date.
>>>         WHAT YOU MIGHT HEAR:
>>>                 - Bill Gates
>>>                 - Steve Jobs
>>>         CORRECT:
>>>                 - Thompson & Ritchie, all the way! :-)
>>>                 - Alan Turing
>>>                 - The great Structured Programming trio: Hoare,
>>> Dijkstra, and Dahl
>>>                 - Knuth
>
> Oh and if you like using transistors for compution,  Pingala had an
> interserting contribution.

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

[Skip Tavakkolian]

> While we are at it... lets remember that young people don't know any
> history.  Everyone knows that the first language with garbage
> collection was Visual Basic.

i believe i'm witness to a transformation (i'm not being sarcastic; i
really think it's true).

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

[Skip Tavakkolian]

9fans is an antisocial network.

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

[Bruce Ellis]

John the Apostle wasn't real.  Mark V. Shaney was.

brucee

On Feb 19, 2008 11:39 AM, Brantley Coile <brantley@coraid.com> wrote:
>
> >>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.
> >
> > Don't diss brucee. He's one of the few reasons for still keeping a
> > tenth of an eye on the list. These days I even miss Choate. "Let he
> > without stone cast the first stone" was pure genius. Most of all I
> > miss the benign presence of Presotto, forever attempting to pour oil
> > on troubled waters.
>
> Small point.  The quote is `Let he who is without sin cast the first stone.'
>                Johh 8:7
>
>   And Jesus said, ``Heither do I condemn you; go; and from now on sin
>   no more.''
>
>
>
>

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

[maht]

> John the Apostle wasn't real.  Mark V. Shaney was.
>
> brucee
>

http://www.topix.com/forum/source/kxtv/TQR5S1VOO7F7DV3P6#c5

he's still posting

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

[Uriel]

"For the sinner deserves not life but death, according to the disk
devices.  For example, start with Plan 9, which is free of sin, the
case is different from His perspective."

    -- Mark V. Shaney - http://danny.oz.au/danny/humour/shaney1

On Feb 19, 2008 5:11 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> John the Apostle wasn't real.  Mark V. Shaney was.
>
> brucee
>
>
> On Feb 19, 2008 11:39 AM, Brantley Coile <brantley@coraid.com> wrote:
> >
> > >>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.
> > >
> > > Don't diss brucee. He's one of the few reasons for still keeping a
> > > tenth of an eye on the list. These days I even miss Choate. "Let he
> > > without stone cast the first stone" was pure genius. Most of all I
> > > miss the benign presence of Presotto, forever attempting to pour oil
> > > on troubled waters.
> >
> > Small point.  The quote is `Let he who is without sin cast the first stone.'
> >                Johh 8:7
> >
> >   And Jesus said, ``Heither do I condemn you; go; and from now on sin
> >   no more.''
> >
> >
> >
> >
>

Re: [9fans] Google search of the day

[erik quanstrom]

> My understanding has always been that the stack is a fundamental element
> of the x86 architecture. SP and BP registers, later ESP and EBP, are all
> about the stack. All return addresses are stored on the stack. Parameter
> passing relies on it. And I know of no other means of implementing them.
> Except by avoiding call/ret instructions and solely jmp'ing around in a
> true mess of a code. No true "procedures."

while this is true, you are confusing calling convention and architecture.
the arch puts some limits on calling convention, but there is no requirement
to use the stack if you have one.

you could have a calling convention that every function emits a call block
with the arguments at callblock+offset and the return value(s) at callblock-
offset.  doesn't matter if the arch has a stack or not.  you are free to ignore it.
'
> I am almost sure the modern incarnations of FORTRAN (90, or even 77?) do
> support both true procedures and recursion. Though, I have not tried them
> so I do not have a say there.

fortran 95 supports recursion.  this does not imply that the *language*
requires a stack.  it could be done via heap allocation.  i don't know enough
fortran to comment intelligently on how its done.

> Automatic/scoped variables are allocated on the stack frame for procedure
> calls and/or nested code blocks (Flat Assembler's rendition of the IA-32
> "enter" instruction supports up to 32 stack frames). And without them,
> programming would be a lot harder.

some languages -- notibly c -- assume a stack frame.  there are many languages,
like fortran that do not.  you wouldn't notice what the compiler is doing in
those languages.

> There is also the "growing" heap for
> implementing dynamic variables which is quite as problematic as the stack
> because it, too, can grow beyond bounds and give one headaches.

this is an entirely different problem as heap allocations in most languages
are *explicit* thus allowing the programmer to respond to the situation
appropriately.  iirc, v7 sort used a binary search algorithm to figure out
how much memory it could sbrk().  e.g.

	int memsize;

	for(memsize = 1024*1024; memsize >= 4*1024;)
		if(sbrk(memsize)>0)
			break;

- erik

Re: [9fans] Google search of the day

[Eris Discordia]

On Fri, 15 Feb 2008 16:07:59 -0000, erik quanstrom <quanstro@quanstro.net>
wrote:

> while this is true, you are confusing calling convention and
> architecture.
> the arch puts some limits on calling convention, but there is no
> requirement
> to use the stack if you have one.
>
> you could have a calling convention that every function emits a call
> block
> with the arguments at callblock+offset and the return value(s) at
> callblock-
> offset.  doesn't matter if the arch has a stack or not.  you are free to
> ignore it.
> '

The calling conventions I have seen are the ccall, stdcall (Windows'
slightly modified version of the ccall), and pascal. All of them push
parameters on the stack.

On x86 (the only architecture I have seen), the return address is pushed
on the stack as soon as something like "call 0x04500" or "call _myfunc" is
executed. Not popping the right number of parameters before executing ret
has times over been a problem with my programs.

I understand that the push order and marshalling strategy
(by-value/by-reference) need not be the same from one language to the
other. Still, all "implementations" of languages on x86 (even FORTRAN,
according to my copy of Steven Holzner's Advanced Assembly Programming)
"have" to push their parameters on stack. I cannot see any other way to
keep the bare minimum required for a procedure call: the return address,
that is. Probably because I do not understand the notion of a "callblock."


> some languages -- notibly c -- assume a stack frame.  there are many
> languages,
> like fortran that do not.  you wouldn't notice what the compiler is
> doing in
> those languages.

You mean, if I disassemble a FORTRAN-compiled binary I will not see the
classical EBP/ESP manipulation at the beginning of each procedure with
automatic variables? I have disassembled C-compiled binaries and seen that
(actually did it so that I could do the same in my assemly programs).

----snippet----
;enter the stack frame
	push	ebp
	mov	ebp, esp
;reserve stack space for a 32-bit automatic variable
	sub	ebp, 04h

;leave the stack frame
	mov	esp, ebp
	pop	ebp
;returning requires the return address
;(the previous value of EIP) pushed on the stack
	ret
----snippet----

On Fri, 15 Feb 2008 16:43:22 -0000, maht <mattmobile@proweb.co.uk> wrote:

> The threaded / concatanative  langauges such as Forth / Joy / Cat / V
> don't use a call stack, though they still use a stack for parameter
> manipulation.

I have heard Forth is used for writing bootloaders (FreeBSD's loader was
written in Forth last time I checked). If the architecture is x86, then
issuing a call (op-code 0x9A+[ModRM]) certainly pushes EIP on the stack.
Perhaps they use jmp for branching.

> http://en.wikipedia.org/wiki/Stackless_Python
>
> Is it the same sort of stack ?

Python is an "interpreted" language (like Perl). Everything is implemented
on a semi-virtual machine (they usually call it the engine). Not sure
their stack is the same as the x86 stack segment.

"Stackless Python, or Stackless, is an experimental implementation of the
Python programming language, so named because it avoids depending on the C
call stack for its own stack. The language supports generators,
microthreads, and coroutines." --Wikipedia

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

[9fans] Non-stack-based calling conventions

[Lyndon Nerenberg]

>
> The calling conventions I have seen are the ccall, stdcall (Windows'
> slightly modified version of the ccall), and pascal. All of them
> push parameters on the stack.

Take a look at the R-call and S-call conventions used on the IBM
System 360 architecture. These machines didn't even have a stack.

--lyndon

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

[Pietro Gagliardi]

- DOS interrupt function calls use the registers, not the stack.
- SPARC and MIPS registers are provided to pass parameters.

On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:

>>
>> The calling conventions I have seen are the ccall, stdcall
>> (Windows' slightly modified version of the ccall), and pascal. All
>> of them push parameters on the stack.
>
> Take a look at the R-call and S-call conventions used on the IBM
> System 360 architecture. These machines didn't even have a stack.
>
> --lyndon

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

[Paweł Lasek]

I don't have latest version of fascicle one (MMIX processor
architecture and MMIXAL assembler language, from new version of The
Art of Computer Programming) at hand, so I can't confirm it, but I
remember that MMIX had a special register which implemented a
"border", shifting register numbers to use them for procedure data
separation.

And as in all RISC architectures, storing as many parameters in the
call stack is the way to go. Especially when you have 256 64-bit
general purpose registers :-) (Now if only someone implemented a sane
architecture using MMIX as main processor...)


On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote:
> - DOS interrupt function calls use the registers, not the stack.
> - SPARC and MIPS registers are provided to pass parameters.
>
> On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
>
> >>
> >> The calling conventions I have seen are the ccall, stdcall
> >> (Windows' slightly modified version of the ccall), and pascal. All
> >> of them push parameters on the stack.
> >
> > Take a look at the R-call and S-call conventions used on the IBM
> > System 360 architecture. These machines didn't even have a stack.
> >
> > --lyndon
>
>


--
Paul Lasek

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

[Brantley Coile]

Early Control Data machines, like many machines
of the era, used the return address to fine the parameters.
This meant that you put he parameters in the instruction
stream right after the call to the subroutine.

Here's the calling convention for your entertainment.

 1) The calling program would put the parameters into memory
    locations just past the call to the subroutine.
 2) Do a return-jump to the subroutine.  This puts the return
    address in the first word of the subroutine and
    begins to execute the second word.
 3) Parameters are accessed by using and incrementing the
    return address.
 4) With the return address now safely stored in the first
    word of the subroutine, we can now return to the
    calling routine just by doing a indirect jump thru
    the first word of the routine.

    All this might not make sense to you so here is some code.
    This is CDC 1830 assembler, the best I can remember it.
    CDC 6600 works the same, but the code would be more
    confusing to the unfamiliar.

          .
          .
    * call sub(p1, p2)
          ena   parm1         put the parameter into the A register
          sta   p1            save it in the instruction stream right after the rtj
          ena	parm2         we have two parameters.
          sta	p2
          rtj   sub           save RA at sub, begin executing at sub+1
    p1    bss   1
    p2    bss   1
          jmp   error
    * first address to return to

          .
          .
          .
    sub   bss   1              place to keep the return address
          ldq   sub
          lda   (q)
          inq   1               point to next parameter
          lda   (q)
          inq   2               point to last parameter and no error
          stq   sub             put parameter back
          jmp   (sub)           jmp indirect thru sub--return

 By convention there we would follow the parameters with a jump
 to an error handler and have the subroutine increment the RA
 another time in case the subroutine had no error.

 The IBM 7094 did a similar trick only it put the return address,
 or I should say the 2's complement of it, in an index register
 before it jumped to the subroutine.  Parameters were picked up
 using the index register.  (7094 indexes seem strange to us now, but
 they were *subtracted* from the base address in the instruction.)
 The subroutine used a form of the transfer instruction that added
 the number of words to the return address, er, I mean subtracted,
 to return to the caller.

 All the memory you would need was known as compile time.
 Writing assembler meant watching for trying to execute
 parameters as instructions.  This does wonders for the design
 of the instruction cache. :)

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

[Eris Discordia]

On Fri, 15 Feb 2008 23:39:40 -0000, Pietro Gagliardi <pietro10@mac.com>
wrote:

> - DOS interrupt function calls use the registers, not the stack.
> - SPARC and MIPS registers are provided to pass parameters.
>
> On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
>
>>>
>>> The calling conventions I have seen are the ccall, stdcall (Windows'
>>> slightly modified version of the ccall), and pascal. All of them push
>>> parameters on the stack.
>>
>> Take a look at the R-call and S-call conventions used on the IBM System
>> 360 architecture. These machines didn't even have a stack.
>>
>> --lyndon
>

Good pieces of info. By the way, MS-DOS software interrupts were
interrupts after all, i. e. different from procedure calls. Using the
stack there would create re-entry problems (?) and a serious performance
bottleneck (heh, MS-DOS to performance is Pumpkins to what?).

On Sat, 16 Feb 2008 00:23:22 -0000, Brantley Coile <brantley@coraid.com>
wrote:

> Early Control Data machines, like many machines
> of the era, used the return address to fine the parameters.
> This meant that you put he parameters in the instruction
> stream right after the call to the subroutine.
>
> Here's the calling convention for your entertainment.
>
>  1) The calling program would put the parameters into memory
>     locations just past the call to the subroutine.
>  2) Do a return-jump to the subroutine.  This puts the return
>     address in the first word of the subroutine and
>     begins to execute the second word.
>  3) Parameters are accessed by using and incrementing the
>     return address.
>  4) With the return address now safely stored in the first
>     word of the subroutine, we can now return to the
>     calling routine just by doing a indirect jump thru
>     the first word of the routine.
>    All this might not make sense to you so here is some code.

In fact, your explanation made much more sense than the code. To me, of
course. The question of why would anyone devise such a weird scheme of
calling procedures remains.

> All the memory you would need was known as compile time.

At the cost of transforming relocation into black magic. Were there
binaries on that platform? Did those binaries need relocation? With code
and data intermingled, there must have also been serious problems with
minimizing binary sizes. All the "empty" words at the beginning of each
subroutine had to be written to permanent storage, I guess. The x86 stack
consumes zero space on permanent storage.

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

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

[Pietro Gagliardi]

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

On Feb 16, 2008, at 6:32 PM, Eris Discordia wrote:

> Using the stack there would create re-entry problems

Under very specific conditions you can do

	PUSH Param1
	PUSH Param2
	PUSH Param3
	INT 80h

What are those conditions?

	- Pascal calling convention
	- You save the registers before PUSHing the first argument

For now, my OS does this as a temporary method of avoiding the
necessity of managing different numbers of registers. This will
change in due time!


[-- Attachment #2: Type: text/html, Size: 1720 bytes --]

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

[Brantley Coile]

>> Early Control Data machines, like many machines
>> of the era, used the return address to fine the parameters.
>> This meant that you put he parameters in the instruction
>> stream right after the call to the subroutine.
>>
>> Here's the calling convention for your entertainment.
>>
>>  1) The calling program would put the parameters into memory
>>     locations just past the call to the subroutine.
>>  2) Do a return-jump to the subroutine.  This puts the return
>>     address in the first word of the subroutine and
>>     begins to execute the second word.
>>  3) Parameters are accessed by using and incrementing the
>>     return address.
>>  4) With the return address now safely stored in the first
>>     word of the subroutine, we can now return to the
>>     calling routine just by doing a indirect jump thru
>>     the first word of the routine.
>>    All this might not make sense to you so here is some code.
>
> In fact, your explanation made much more sense than the code. To me, of
> course. The question of why would anyone devise such a weird scheme of
> calling procedures remains.

This was the dawn of computer time, and the machines had few registers.
The basic Wheeler Jump on the EDSAC, the first operational stored
program computer, consisted of loading the address of the parameters
following the jump into the accumulator before jumping to the subroutine.
With so few registers, it is natural to use the return address
to get at both the parameters and figure out where to return.

In other words, this is what we did before we figured out a better way.

Don't ask about index registers.  (add 1 to the instruction and execute it.)

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

[Brantley Coile]

>> All the memory you would need was known as compile time.
>
> At the cost of transforming relocation into black magic. Were there
> binaries on that platform? Did those binaries need relocation? With code
> and data intermingled, there must have also been serious problems with
> minimizing binary sizes. All the "empty" words at the beginning of each
> subroutine had to be written to permanent storage, I guess. The x86 stack
> consumes zero space on permanent storage.

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.

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.

All was much simpler than today.

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

[Eris Discordia]

On Sun, 17 Feb 2008 00:04:31 -0000, Brantley Coile <brantley@coraid.com>
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/

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

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

[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 <quanstro@quanstro.net> 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]

> 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 <quanstro@quanstro.net> 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

[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 <quanstro@quanstro.net> 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

[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

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
<hydrologiccycle@gmail.com> 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

[Anant Narayanan]

Just as an observation (may not be related to the thread), all the
executable file formats that Linux currently supports, have page-
aligned sections in the file! (Now I know why hexdump always shows me
a bunch of zeros in-between).

That means, all the loader really does is mmap the sections into the
right memory locations. What next, maybe also put in the BSS in the
file so you wouldn't have to allocate that either ;)

Hence, writing the loader for Plan 9's a.out proved to be a challenge.

I ended up writing a user-space program that padded out the required
gap between TEXT and DATA before asking the kernel to execute it.
Suboptimal, but it works.

If anyone has any ideas as to how I can improve the situation, i'll be
grateful.

Thanks,
Anant

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

[Douglas A. Gwyn]

Anant Narayanan wrote:
> Just as an observation (may not be related to the thread), all the
> executable file formats that Linux currently supports, have page-
> aligned sections in the file! ...
> That means, all the loader really does is mmap the sections into the
> right memory locations. What next, maybe also put in the BSS in the
> file so you wouldn't have to allocate that either ;)

Ssh, somebody may hear you and decide to do it.
Conceptually it's not a bad idea, in environments where you can
spare the wasted space.  As I recall, using the VM system to map
files in Unix goes back to 4BSD; we used to page-align buffer
addresses in order to get the kernel to perform faster data
transfers.

> Hence, writing the loader for Plan 9's a.out proved to be a challenge.
> I ended up writing a user-space program that padded out the required
> gap between TEXT and DATA before asking the kernel to execute it.
> Suboptimal, but it works.
> If anyone has any ideas as to how I can improve the situation, i'll be
> grateful.

I don't understand what good it does to map Plan 9 object code
into Linux files.  Is there a Linux filetype for Plan 9 that
invokes a system-call interpreter, or what?

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

[Anant Narayanan]

On 22-Feb-08, at 3:32 PM, Douglas A. Gwyn wrote:
> I don't understand what good it does to map Plan 9 object code
> into Linux files.  Is there a Linux filetype for Plan 9 that
> invokes a system-call interpreter, or what?

No, I just write a handler for interrupt 0x64 that calls either  an
existing linux syscall (it works for some of them) or a custom in-
kernel routine (for the more 'exotic' plan 9 syscalls).

Yes, the project is currently aimed at x86 only.

--
Anant

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

[Anant Narayanan]

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

Wow, that makes two of you. Real Impressive.

--
Anant

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

[Bruce Ellis]

grep impressed /sys/games/lib/fortunes

On Feb 18, 2008 7:30 PM, Anant Narayanan <anant@kix.in> wrote:
> > 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.
>
> Wow, that makes two of you. Real Impressive.
>
> --
> Anant
>

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

[Federico G. Benavento]

hola,

> 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.
>
really? I don't even know bruce, but his posts are one of the things that
make this list worth reading.

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

wtf is linus?  I _had_ to be some wannabe it wouldn't be a linus one,
maybe a ken wannabe, but who wants to be a wannabe anyways?

--
Federico G. Benavento

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

[Lorenzo Fernando Bivens de la Fuente]

This is the best community *ever*

Software, hardware, phylosophy, politics, economics... Whatever the
discussion is, the best arguments are around this list.

It is not perfect, though... But each post, each member, makes it special...

(sha-la-la-la-la...)

:D

On Mon, Feb 18, 2008 at 6:50 PM, Federico G. Benavento
<benavento@gmail.com> wrote:
> hola,
>
>
>  > 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.
>  >
>  really? I don't even know bruce, but his posts are one of the things that
>  make this list worth reading.
>
>
>  > 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.
>
>  wtf is linus?  I _had_ to be some wannabe it wouldn't be a linus one,
>  maybe a ken wannabe, but who wants to be a wannabe anyways?
>
>  --
>  Federico G. Benavento
>

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

[y i y u s]

2008/2/18, Lorenzo Fernando Bivens de la Fuente <lorenzobivens@gmail.com>:
> This is the best community *ever*
>
> Software, hardware, phylosophy, politics, economics... Whatever the
> discussion is, the best arguments are around this list.
>


I agree 100%. As one of the persons subscribed to the list in "read
only mode" I have to tell I love it. You are miles ahead of that rtfm
catch phrase. When I see a post saying "let's port gcc" I smile
thinking "this is going to be funny..." I really learn here, and I
love what I call the "uriel/bruce touch" (I have learned now that it
is a bit of "boyd touch", but I arrived here a bit too late for
that...).
I was just waiting to see somebody throwing the first stone to say how
I love reading 9fans.

keep the good work,

--


- yiyus || JGL .

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

[Uriel]

> I agree 100%. As one of the persons subscribed to the list in "read
> only mode" I have to tell I love it. You are miles ahead of that rtfm
> catch phrase. When I see a post saying "let's port gcc" I smile
> thinking "this is going to be funny..." I really learn here, and I
> love what I call the "uriel/bruce touch" (I have learned now that it
> is a bit of "boyd touch", but I arrived here a bit too late for
> that...).

You (and everyone) should read the archives, they are pure gold, the
quality of the discussion in 9fans has been steadily degenerating over
the years... but as fgb pointed out people like brucee still make it
worth reading.

uriel

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

[Pietro Gagliardi]

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

On Feb 18, 2008, at 1:50 PM, Federico G. Benavento wrote:

> wtf is linus?

Vivete sotto una roccia?


[-- Attachment #2: Type: text/html, Size: 462 bytes --]

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

[Pietro Gagliardi]

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

Sorry, intended that to be private.

On Feb 18, 2008, at 5:14 PM, Pietro Gagliardi wrote:

> On Feb 18, 2008, at 1:50 PM, Federico G. Benavento wrote:
>
>> wtf is linus?
>
> Vivete sotto una roccia?
>


[-- Attachment #2: Type: text/html, Size: 714 bytes --]

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

[Federico G. Benavento]

> Vivete sotto una roccia?

I'm glad I took a latin semester, it helps to decode
latin derived languages.

--
Federico G. Benavento

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

[maht]

I'll preceed my invective with something relevant :

Forth's calling convention means the stack is used less for nested calls.

For the C version there's all sorts of pushing and popping return
addresses and arguments on to the stack

float
sqr(x float)
{
    return x * x;
}

float
hyp(x float, y float)
{
    return sqrt(sqr(x) + sqr(y));
}

Whereas in the Forth version, the only thing that gets pushed and popped
is the address of the next function, the arguments are on the stack
already (assume the FP versions of the Words are used) :

:sqr dup *
:hyp sqr over sqr + sqrt


Now on with the invective



lolz, I go away for 3 days and I must have left the back door open
because when I came back the place was full of ignorant bitches.

I like both of these :

grep impressive /sys/games/lib/fortune

I'm glad that the "problem" of Plan 9 has been solved at last, it's the
people who have been using it for n years.

My personal n started on June 7 2000, I guess that day is akin to "the
September that Never Ended" to those for whom n > 7.

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

[Bruce Ellis]

http://www.videojug.com/film/how-to-behave-on-an-internet-forum

On Feb 20, 2008 10:39 PM, maht <mattmobile@proweb.co.uk> wrote:
> ...
>
> lolz, I go away for 3 days and I must have left the back door open
> because when I came back the place was full of ignorant bitches.
>
> ...

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

[Douglas A. Gwyn]

maht wrote:
> For the C version there's all sorts of pushing and popping return
> addresses and arguments on to the stack
> float
> sqr(x float)
> {
>     return x * x;
> }
> float
> hyp(x float, y float)
> {
>     return sqrt(sqr(x) + sqr(y));
> }

[Assuming that the code is corrected and the types made compatible
with the argument to sqrt.]
The extra overhead occurs only because of the support for full
recursion, with private instance data.  Many C compilers dating
back to around 1980 will in-line the calls to sqr, so the effect is:
hyp:	mul	r2,r2,r2
	mul	r3,r3,r3
	add	r2,r3,r2
	jmp	sqrt
It's hard to imagine anything more efficient (except when hyp
itself can be in-lined.)  Details of course depend on the machine
architecture and linkage convention; the above is modeled loosely
after the M*CORE, which is very nice in this respect.

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

[Douglas A. Gwyn]

"Federico G. Benavento" wrote:
> ... but who wants to be a wannabe anyways?

Maybe a has-been wannabe has wanted to be?

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

[LiteStar numnums]

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

Hullo,
 Athens voted to give Socrates a farewell toast; it wasn't particularly
useful to anyone involved. brucee might've been acerbic, but you risk having
your statements answered acerbically on teh interwebs & off. I, for one,
enjoy reading almost 100% of what's posted to 9fans, and of the few times
that I have written brucee, all have been met with the same courteous, if
terse, style. I'd hate to lose anyone who posts to 9fans, not the least of
whom would be Erik nor brucee.
Cheers,
 -- LS

On Feb 18, 2008 1:22 AM, Robert William Fuller <hydrologiccycle@gmail.com>
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
>



--
   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 2275 bytes --]

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

[Pietro Gagliardi]

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

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.


[-- Attachment #2: Type: text/html, Size: 929 bytes --]

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

[Pietro Gagliardi]

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

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


[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

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 <pietro10@mac.com> 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] Non-stack-based calling conventions

[Anthony Sorace]

On 2/17/08, Eris Discordia <eris.discordia@gmail.com> 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

[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

[Douglas A. Gwyn]

Eris Discordia wrote:
> do Plan 9 compilers output COFF object files?

No, it has its own format.  Actually Plan 9 is interesting
in that some of the work traditionally done by the compiler
was made the responsibility of the linker.

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

[Iruata Souza]

On Fri, Feb 22, 2008 at 7:01 AM, Douglas A. Gwyn <DAGwyn@null.net> wrote:
> Eris Discordia wrote:
>  > do Plan 9 compilers output COFF object files?
>
>  No, it has its own format.  Actually Plan 9 is interesting
>  in that some of the work traditionally done by the compiler
>  was made the responsibility of the linker.
>

like douglas said, the linkers will do the job and output COFF for you.

iru

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

[Douglas A. Gwyn]

Brantley Coile wrote:
> ... 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.

Also, the 1700 linking and program loading were done at the same time,
the linker had to traverse threaded references and perform relocation
on those that needed it.  I created  a portable implementation of the
linker some time ago (the assembler is on hold until my retirement).

> All was much simpler than today.

Although in a virtual-memory environment no relocation is needed at
program load time.

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

[Douglas A. Gwyn]

Brantley Coile wrote:
> Early Control Data machines, like many machines
> of the era, used the return address to find the parameters.
> This meant that you put he parameters in the instruction
> stream right after the call to the subroutine.
> ...

Yes, a lot of minicomputers did that in those days.  Even on the
PDP-11, which had nice support for stack operations, some system-
call conventions involved embedding parameters in-line.  Unix did
that too, although at some point an "indirect" call was added to
fetch the parameter block from a pointed-to location.

If you have and CDC Cyber 18 (or 1700) system software, I am
desperate to obtain a copy for use with my 1700 emulation.

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

[Lluís Batlle]

Talking about The Art of Computer Programming... this non-stack based
calling convention made me think of Knuth's Coroutines. I'm quite
interested on them, but although I've seen libraries for managing
them, I've never seen a real useful program based on them. I think
they could be used with advantages over the thread or normal function
call abstractions.

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

2008/2/16, Paweł Lasek <pawel.lasek@gmail.com>:
> I don't have latest version of fascicle one (MMIX processor
> architecture and MMIXAL assembler language, from new version of The
> Art of Computer Programming) at hand, so I can't confirm it, but I
> remember that MMIX had a special register which implemented a
> "border", shifting register numbers to use them for procedure data
> separation.
>
> And as in all RISC architectures, storing as many parameters in the
> call stack is the way to go. Especially when you have 256 64-bit
> general purpose registers :-) (Now if only someone implemented a sane
> architecture using MMIX as main processor...)
>
>
> On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote:
> > - DOS interrupt function calls use the registers, not the stack.
> > - SPARC and MIPS registers are provided to pass parameters.
> >
> > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
> >
> > >>
> > >> The calling conventions I have seen are the ccall, stdcall
> > >> (Windows' slightly modified version of the ccall), and pascal. All
> > >> of them push parameters on the stack.
> > >
> > > Take a look at the R-call and S-call conventions used on the IBM
> > > System 360 architecture. These machines didn't even have a stack.
> > >
> > > --lyndon
> >
> >
>
>
> --
> Paul Lasek
>

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:

<http://research.swtch.com/2008/01/on-duffs-device-and-coroutines.html>

	-Chad

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

[Pietro Gagliardi]

It says here that setjmp can be used to make coroutines:

http://my.execpc.com/~geezer/osd/tasks/index.htm

On Feb 16, 2008, at 3:29 AM, Lluís Batlle wrote:

> Talking about The Art of Computer Programming... this non-stack based
> calling convention made me think of Knuth's Coroutines. I'm quite
> interested on them, but although I've seen libraries for managing
> them, I've never seen a real useful program based on them. I think
> they could be used with advantages over the thread or normal function
> call abstractions.
>
> Maybe someone in this list can provide a good example of coroutines  
> use?
>
> 2008/2/16, Paweł Lasek <pawel.lasek@gmail.com>:
>> I don't have latest version of fascicle one (MMIX processor
>> architecture and MMIXAL assembler language, from new version of The
>> Art of Computer Programming) at hand, so I can't confirm it, but I
>> remember that MMIX had a special register which implemented a
>> "border", shifting register numbers to use them for procedure data
>> separation.
>>
>> And as in all RISC architectures, storing as many parameters in the
>> call stack is the way to go. Especially when you have 256 64-bit
>> general purpose registers :-) (Now if only someone implemented a sane
>> architecture using MMIX as main processor...)
>>
>>
>> On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote:
>>> - DOS interrupt function calls use the registers, not the stack.
>>> - SPARC and MIPS registers are provided to pass parameters.
>>>
>>> On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
>>>
>>>>>
>>>>> The calling conventions I have seen are the ccall, stdcall
>>>>> (Windows' slightly modified version of the ccall), and pascal. All
>>>>> of them push parameters on the stack.
>>>>
>>>> Take a look at the R-call and S-call conventions used on the IBM
>>>> System 360 architecture. These machines didn't even have a stack.
>>>>
>>>> --lyndon
>>>
>>>
>>
>>
>> --
>> Paul Lasek
>>

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

[Douglas A. Gwyn]

Lluís Batlle wrote:
> Maybe someone in this list can provide a good example of coroutines use?

Check out http://en.wikipedia.org/wiki/Coroutine for examples and discussion.

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

[Paweł Lasek]

I've got some time to delve into Fascicle One again and indeed, MMIX
doesn't have any stack at all. When you need stack, you implement it
yourself. Anyone knows of other CPU's using this method for stack
(i.e. no in-built support for stack in memory)? There is stack based
on registers, though.

On Sat, Feb 16, 2008 at 12:47 AM, Paweł Lasek <pawel.lasek@gmail.com> wrote:
> I don't have latest version of fascicle one (MMIX processor
>  architecture and MMIXAL assembler language, from new version of The
>  Art of Computer Programming) at hand, so I can't confirm it, but I
>  remember that MMIX had a special register which implemented a
>  "border", shifting register numbers to use them for procedure data
>  separation.
>
>  And as in all RISC architectures, storing as many parameters in the
>  call stack is the way to go. Especially when you have 256 64-bit
>  general purpose registers :-) (Now if only someone implemented a sane
>  architecture using MMIX as main processor...)
>
>
>
>
>  On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote:
>  > - DOS interrupt function calls use the registers, not the stack.
>  > - SPARC and MIPS registers are provided to pass parameters.
>  >
>  > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
>  >
>  > >>
>  > >> The calling conventions I have seen are the ccall, stdcall
>  > >> (Windows' slightly modified version of the ccall), and pascal. All
>  > >> of them push parameters on the stack.
>  > >
>  > > Take a look at the R-call and S-call conventions used on the IBM
>  > > System 360 architecture. These machines didn't even have a stack.
>  > >
>  > > --lyndon
>  >
>  >
>
>
>  --
>  Paul Lasek
>



-- 
Paul Lasek

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

[maht]

I'm quoting out of context as they were discussing the design of the
Inferno VM but Phil Winterbottom & Rob Pike mention in
http://www.vitanuova.com/inferno/papers/hotchips.html :

"One might argue that a stack-based processor design would mitigate the
difficulties, but our experience with the implementation of a stack
machine in the AT&T Crisp microprocessor [5] leads us to believe that
stack architectures are inherently slower than register-based machines.
Their design lengthens the critical path by replacing simple registers
with a complex stack cache mechanism."

5. Ditzel, D. R. and McLellan, R., ``Register Allocation for Free: The C
Machine Stack Cache'', Proc. of Symp. on Architectural Support for
Programming Languages and Operating Systems, March, 1982, pp. 48-56.

I found the paper at http://portal.acm.org/citation.cfm?id=960120.801825
but you have to have a paid account so I have no idea of their
conclusions beyond Rob & Phil's comment
It is a widely cited paper though, so it must be a good read. (and I did
find loads of other great stuff while trying to find it)

The Crisp sounds like something interesting, anyone know much about it?

I found this again at acm
Design tradeoffs to support the C programming language in the CRISP
microprocessor
http://portal.acm.org/citation.cfm?id=36198&coll=portal&dl=ACM

and this at ieee
CRISP: a pipelined 32-bit microprocessor with 13-kbit of cache memory
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/4/22616/01052813.pdf

seems that information doesn't want to be free today

> I've got some time to delve into Fascicle One again and indeed, MMIX
> doesn't have any stack at all. When you need stack, you implement it
> yourself. Anyone knows of other CPU's using this method for stack
> (i.e. no in-built support for stack in memory)? There is stack based
> on registers, though.
>

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

[Brantley Coile]

> I'm quoting out of context as they were discussing the design of the
> Inferno VM but Phil Winterbottom & Rob Pike mention in
> http://www.vitanuova.com/inferno/papers/hotchips.html :
>
> "One might argue that a stack-based processor design would mitigate the
> difficulties, but our experience with the implementation of a stack
> machine in the AT&T Crisp microprocessor [5] leads us to believe that
> stack architectures are inherently slower than register-based machines.
> Their design lengthens the critical path by replacing simple registers
> with a complex stack cache mechanism."

I haven't been following the Non-stack-based calling thread
closely, but this comment is not about using the stack
in procedure calls.  They are talking about stack *machines*.

 push value
 push value
 add
 pop value

The Pacal P-machine, the Lillith microcode and the Java Byte machine
all come to mind.  Note about calling.  Intersting in any case.

Ken Thompson seemed to be absent at most Usenix conferences, but at
one I saw him line up at the mike after the talk on the BSD
packet filter.  He asked why they had used a stack machine.  The
poor fellow, who recognized who was asking the question looked
like a deer suddenly lit by the headlights of a Peterbuilt.

  `It's faster?'

  `No, it's not!'

End of questions.

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

[Uriel]

>  Ken Thompson seemed to be absent at most Usenix conferences, but at
>  one I saw him line up at the mike after the talk on the BSD
>  packet filter.  He asked why they had used a stack machine.  The
>  poor fellow, who recognized who was asking the question looked
>  like a deer suddenly lit by the headlights of a Peterbuilt.
>
>   `It's faster?'
>
>   `No, it's not!'
>
>  End of questions.

I would pay good money for a video of this exchange...

uriel

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

[Brantley Coile]

> 5. Ditzel, D. R. and McLellan, R., ``Register Allocation for Free: The C
> Machine Stack Cache'', Proc. of Symp. on Architectural Support for
> Programming Languages and Operating Systems, March, 1982, pp. 48-56.

Some where in my junk I still have the description of the C70
machine from BBN.  No assembler.  Calls to odd addresses called
microcode.

Just an aside.

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

[Bruce Ellis]

Dis on a Chip is not stack based.  There are no stacks at all.
A very real advantage is that there are hence no restartable
faults.  If my memory serves me right this was the reason that
the C compiler for the Cray XMP had segmented stacks.
(A call would check if there was enough left in the current
segment and if not malloc and link another segment - yes it
was fast enough to get away with this.)

brucee

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

[lucio]

> I've got some time to delve into Fascicle One again and indeed, MMIX
> doesn't have any stack at all. When you need stack, you implement it
> yourself. Anyone knows of other CPU's using this method for stack
> (i.e. no in-built support for stack in memory)? There is stack based
> on registers, though.

Current or obsolete architectures?  The Sperry Univac 1100 Series,
designed by Seymour Craye (sp?  it's been a long time) had no hardware
supported stack, although it had a bit in the 36-bit instruction that
caused the signed upper half of the selected index register to be
added to the lower half.  I don't remember whether it was before or
after applying the index to the base address in the lower 16 bits of
the instruction, it would need to be fixed one way (post-increment, I
think) because it was unlikely to check the sign of the upper half
before deciding.

Bloody marvellous, it was.  Specially as it was the first computer I
ever worked on.  I have extremely fond memories of it.  I can easily
wax nostalgic about it.  Hm, maybe I should look for a simulator for
it, anyone know of one?

++L

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

[ron minnich]

On Tue, Feb 26, 2008 at 8:26 PM,  <lucio@proxima.alt.za> wrote:

>  Current or obsolete architectures?  The Sperry Univac 1100 Series,
>  designed by Seymour Craye (sp?

Cray.

I had no idea he designed it. It had a great front panel -- the lights
were switches.

I operated an 1108 as a student at E.I. Dupont de Nemours et. ci. in
WIlmington, DE.

Among other things, it ran "the Freon simulation", which evidently
helped make up Dupont's mind on
the ozone.

Ours had a drum memory. The drum was about 20 feet long, two per
cabinet, moving them required
creating a hole in the side of the building and moving them with a crane.

I once slipped while emptying the card reader
and hit about 30 switches at once with my upper arm. The machine
locked up. That's where I learned
an important lesson: figure out if anyone saw you, walk away slowly,
make no eye contact,  "must be that software
bug again" ... works every time.


>  Bloody marvellous, it was.  Specially as it was the first computer I
>  ever worked on.  I have extremely fond memories of it.  I can easily
>  wax nostalgic about it.  Hm, maybe I should look for a simulator for
>  it, anyone know of one?

That would be fun, but you'd have to find Exec 8, right?

Ah, the days of lights and switches. Today's machines have no soul.

ron

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

[lucio]

> That would be fun, but you'd have to find Exec 8, right?

Well, I suppose, if only because the EXEC subset of the assembler
language was so unfamiliar :-)

But the head of computing at the University of Cape Town used to be an
international expert on Exec 8, so he may still have a copy.

Now that you remind me, "load function in channel" never really meant
a thing to me, so I think I'll skip being clever.

Oh, as for the drum, at UCT we had frequency fluctuations in the
mains, causing the synchronous motors of the drum to speed up and slow
down, causing parity errors.  Given that the exec code lived on drum,
swapping it in under such conditions caused lock ups.  Took many
months to pin it down to supply problems.

++L

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

[Bill Gunshannon]

In article <2ca539b9873bc2cd75592dc3b1e40eb8@proxima.alt.za>,
	lucio@proxima.alt.za writes:
>> That would be fun, but you'd have to find Exec 8, right?
>
> Well, I suppose, if only because the EXEC subset of the assembler
> language was so unfamiliar :-)
>
> But the head of computing at the University of Cape Town used to be an
> international expert on Exec 8, so he may still have a copy.
>
> Now that you remind me, "load function in channel" never really meant
> a thing to me, so I think I'll skip being clever.
>
> Oh, as for the drum, at UCT we had frequency fluctuations in the
> mains, causing the synchronous motors of the drum to speed up and slow
> down, causing parity errors.  Given that the exec code lived on drum,
> swapping it in under such conditions caused lock ups.  Took many
> months to pin it down to supply problems.

Exec8, drum, sounds like you are talking about a Univac-1100 (I came
in late, sorry).  I worked with one of those back in the 80's.  We
had a motor-generator between the mains and the computer that took
care of keeping what the computer saw flat and smooth.  I always
thought that was a standard Univac installation.

Hey, while I have your attention.  I am looking for something from
those days that we ran on the Univac at that sight and UCT being
an edu may have also had it.  Ever heard of The Software Tools
Virtual Operating System?  Any chance you have a 9-track with this
on it still hanging around?  I would love to get my hands on a copy
again.

bill

--
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

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

[Charles Forsyth]

> an edu may have also had it.  Ever heard of The Software Tools
> Virtual Operating System?  Any chance you have a 9-track with this
> on it still hanging around?  I would love to get my hands on a copy
> again.

the Software Tools (begun by Kernighan and Plauger's book of the same name) can be found in:

http://www.geocities.com/SiliconValley/Lab/9247/lang/stugbasic.tgz
http://www.geocities.com/SiliconValley/Lab/9247/lang/stugtoys.tgz

the latter includes a LISP written in Ratfor

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

[Bill Gunshannon]

In article <4b3dfa84b440e0780f7cf1472ed6f93b@terzarima.net>,
	forsyth@terzarima.net (Charles Forsyth) writes:
>> an edu may have also had it.  Ever heard of The Software Tools
>> Virtual Operating System?  Any chance you have a 9-track with this
>> on it still hanging around?  I would love to get my hands on a copy
>> again.
>
> the Software Tools (begun by Kernighan and Plauger's book of the same name) can be found in:
>
> http://www.geocities.com/SiliconValley/Lab/9247/lang/stugbasic.tgz
> http://www.geocities.com/SiliconValley/Lab/9247/lang/stugtoys.tgz
>
> the latter includes a LISP written in Ratfor
>

Slight (and quite common) misunderstanding.  This is not the K&P Software
Tools.   This was a graduate project that built on the ideas of K&P to
create an API that at its peak ran on at least 50 different systems.
It was covered in Communications of the ACM September 80.
   http://www.dcs.gla.ac.uk/~joe/auxiliary/ papers/Personal/VirtualOS.pdf

After its release it took on a life of its own for many years.  There was
even a Users Group talking about it and building on it.  Georgia Tech did
the version for Pr1me computers.  U Wisconsin - Madison did the Univac-1100
version.  Etc.  It was pretty slick but unfortunately, like too many parts
of our industry, is seems to have all but disappeared.  It is one of the
things I am trying to salvage not only for posterity, but also because I
think it might have some utility as technology has eliminated its worst
shortcomings with its natural advancements.  Think of this as what later
went on to be called POSIX.  The big difference being STVOS actually worked.
:-)

bill

--
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>