[9fans] quote of the day

[9fans] quote of the day

[erik quanstrom]

from the linux kernel:

	bootsplash: silent mode.

- erik

Re: [9fans] quote of the day

[Pietro Gagliardi]

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

Freenode.net just netsplitted. Here is from the ##c chat room:

saparok
17:59
wow.  I didnt' realize that dd command could take down all of freenode.


On Feb 13, 2008, at 5:03 PM, erik quanstrom wrote:

> from the linux kernel:
>
> 	bootsplash: silent mode.
>
> - erik


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

[9fans] Google search of the day

[dave.l]

On 13 Feb 2008, at 22:03, erik quanstrom wrote:

> 	bootsplash: silent mode.

:-).

(In case anyone hasn't seen this yet ...)

In a different part of the that strange dimension known as
The Linux Zone, someone cryptically pointed me at a hideous exploit via:

     http://www.google.com/search?q=jessica_biel_naked_in_my_bed.c

which I found amusing in a sick way.

DaveL

Re: [9fans] Google search of the day

[Pietro Gagliardi]

In most /bin/sh variants (I'm not sure about original):

	:(){:|:};:

Quick denial of service.

On Feb 13, 2008, at 6:24 PM, dave.l@mac.com wrote:

> On 13 Feb 2008, at 22:03, erik quanstrom wrote:
>
>> 	bootsplash: silent mode.
>
> :-).
>
> (In case anyone hasn't seen this yet ...)
>
> In a different part of the that strange dimension known as
> The Linux Zone, someone cryptically pointed me at a hideous exploit
> via:
>
>     http://www.google.com/search?q=jessica_biel_naked_in_my_bed.c
>
> which I found amusing in a sick way.
>
> DaveL
>

Re: [9fans] Google search of the day

[erik quanstrom]

On Wed Feb 13 18:32:19 EST 2008, pietro10@mac.com wrote:
> In most /bin/sh variants (I'm not sure about original):
>
> 	:(){:|:};:
>
> Quick denial of service.
>


iirc, there were not functions in the orginal.

- erik

Re: [9fans] Google search of the day

[Pietro Gagliardi]

So I think only in bash.

How it works?

http://www.cyberciti.biz/faq/understanding-bash-fork-bomb/

It does use :(){ :|: &};:, but I have tried :(){:|:};: and it worked.

On Feb 13, 2008, at 6:41 PM, erik quanstrom wrote:

> On Wed Feb 13 18:32:19 EST 2008, pietro10@mac.com wrote:
>> In most /bin/sh variants (I'm not sure about original):
>>
>> 	:(){:|:};:
>>
>> Quick denial of service.
>>
>
>
> iirc, there were not functions in the orginal.
>
> - erik

Re: [9fans] Google search of the day

[john]

> In most /bin/sh variants (I'm not sure about original):
>
> 	:(){:|:};:
>
> Quick denial of service.
>

This just in: Repeated forks can bring down a system.
Story at 11.

#include <u.h>
#include <libc.h>

int main() {
	for (;;)
		fork();
}

Look ma!

John

Re: [9fans] Google search of the day

[Pietro Gagliardi]

That is exactly how that shell attack works.

At one point, however, I think that the number of dynamically
allocated task objects should run out, and the program should just
wind about in an infinite loop of erroneous calls to fork(). What a
shame. I'm happy the OS I'm writing does so. It isn't a UNIX-like
one, but the semantics are similar.

On Feb 13, 2008, at 6:59 PM, john@csplan9.rit.edu wrote:

>> In most /bin/sh variants (I'm not sure about original):
>>
>> 	:(){:|:};:
>>
>> Quick denial of service.
>>
>
> This just in: Repeated forks can bring down a system.
> Story at 11.
>
> #include <u.h>
> #include <libc.h>
>
> int main() {
> 	for (;;)
> 		fork();
> }
>
> Look ma!
>
> John
>

Re: [9fans] Google search of the day

[Anant Narayanan]

Both the fork bomb and naked jessica (that's what they're calling it
now) exploits have been fixed in linux for quite a while now.

--
Anant

Re: [9fans] Google search of the day

[Skip Tavakkolian]

>> #include <u.h>
>> #include <libc.h>
>>
>> int main() {
>> 	for (;;)
>> 		fork();
>> }
>>
>> Look ma!
>>
>> John

this is the closest solution i've found:

	Patient: Doctor, it hurts when I do this.
	Doctor: Then don't do that!

Re: [9fans] Google search of the day

[Douglas A. Gwyn]

john@csplan9.rit.edu wrote:
>         for (;;)
>                 fork();

In genuine UNIX(tm) systems, there is a per-user process limit,
so eventually the fork requests start failing.  However, this
program keeps trying to fork, so if you kill off some of the
child processes it will spawn replacements.

I don't think it counts as a proper "denial of service" attack,
since it affects only the invoking user (well, it does bog
down the system with swapping etc. but again, per-user resource
bounds can address that).

Re: [9fans] Google search of the day

[john]

> john@csplan9.rit.edu wrote:
>>         for (;;)
>>                 fork();
>
> In genuine UNIX(tm) systems, there is a per-user process limit,
> so eventually the fork requests start failing.  However, this
> program keeps trying to fork, so if you kill off some of the
> child processes it will spawn replacements.
>
> I don't think it counts as a proper "denial of service" attack,
> since it affects only the invoking user (well, it does bog
> down the system with swapping etc. but again, per-user resource
> bounds can address that).

It's a proper denial of service on Plan 9... I ran it while
cpu'd into another box and found that somehow it killed *both*
machines. IIRC, Plan 9 doesn't really have any kind of resource
limiting, does it? (Yeah, I know, not necessary for a terminal,
but it should be important for a cpu server)


John

Re: [9fans] Google search of the day

[erik quanstrom]

>
> It's a proper denial of service on Plan 9... I ran it while
> cpu'd into another box and found that somehow it killed *both*
> machines. IIRC, Plan 9 doesn't really have any kind of resource
> limiting, does it? (Yeah, I know, not necessary for a terminal,
> but it should be important for a cpu server)
>

this is a problem for unix and plan 9.  as soon as you try resource
limiting, you have a new way to dos a machine.  force the hostowner
(or root) to use up his allotment.  okay, the unix guys have thought
of this and so they limit the number of ssh connections.  the problem
is that if you access as root to the box is via ssh, you're still done.
i don't see an easy systematic solution to this type of problem.

as was discussed a few months ago, any system that has unreserved
stack allocation can suffer from similiar problems.  the oom killer
on linux is a symptom of this kind of problem.

- erik

Re: [9fans] Google search of the day

[Douglas A. Gwyn]

erik quanstrom wrote:
> as was discussed a few months ago, any system that has unreserved
> stack allocation can suffer from similiar problems.  the oom killer
> on linux is a symptom of this kind of problem.

Speaking of such things:

(1) Linux had/has a "feature" where the storage reserved by
malloc/sbrk may be over-committed, so that despite a "success"
indication from the allocation, when the application gets around
to using the storage it could suddenly fail due to there not
being enough to satisfay all current processes.  I urged (but
don't know whether anybody listened) that overcommitment should
be disabled by default, with processes that want it (said to
include "sparse array" programs, which sounds like bad design
but that's another issue) being required to enable it by a
specific request, or at least flagged as special in the
executable object file.  I kludged around this in my portable
malloc implementation by having a configuration flag which if
set caused malloc to attempt to touch every page before
reporting success, trapping SIGSEGV in order to maintain
control.

(2) C, as well as many other PLs, has always had a problem in
that there is no clean, standard mechanism to handle the
situation in which a function invocation finds insufficient
stack remaining to complete the linkage (instance allocation).
This is especially problematic in memory-constrained apps such
as many embedded systems, when the algorithm is sufficiently
dynamic that it is impossible to predict the maximum nesting
depth.  At least with malloc failure, the program is informed
when there is a problem and can take measures to cope with it.

I hope people working on run-time environments will find ways
to do better.

Re: [9fans] Google search of the day

[Alf]

You can turn this off with

# echo 2 > /proc/sys/vm/overcommit_memory

See also the kernel Documentation directory, files
vm/overcommit-accounting and sysctl/vm.txt.


Douglas A. Gwyn wrote:
>
> Speaking of such things:
>
> (1) Linux had/has a "feature" where the storage reserved by
> malloc/sbrk may be over-committed,

Re: [9fans] Google search of the day

[erik quanstrom]

believe it or not plan 9 does exactly the same thing, as was
discussed in august under the subject "plan 9 overcommits memory?".

fundamentally, i think the stack problem is an operating system
problem not a language problem.  (unless you're talking about
8 or 16-bit embedded things.)  the thread library, for example
does just fine requiring its threads to declare a stack size.

in the case of a memory-constrained app on an embedded system,
the solution might be to find/write an algorithm that doesn't need a stack. :-)

- erik

> (1) Linux had/has a "feature" where the storage reserved by
> malloc/sbrk may be over-committed, so that despite a "success"
> indication from the allocation, when the application gets around
> to using the storage it could suddenly fail due to there not
> being enough to satisfay all current processes.  I urged (but
> don't know whether anybody listened) that overcommitment should
> be disabled by default, with processes that want it (said to
> include "sparse array" programs, which sounds like bad design
> but that's another issue) being required to enable it by a
> specific request, or at least flagged as special in the
> executable object file.  I kludged around this in my portable
> malloc implementation by having a configuration flag which if
> set caused malloc to attempt to touch every page before
> reporting success, trapping SIGSEGV in order to maintain
> control.
>
> (2) C, as well as many other PLs, has always had a problem in
> that there is no clean, standard mechanism to handle the
> situation in which a function invocation finds insufficient
> stack remaining to complete the linkage (instance allocation).
> This is especially problematic in memory-constrained apps such
> as many embedded systems, when the algorithm is sufficiently
> dynamic that it is impossible to predict the maximum nesting
> depth.  At least with malloc failure, the program is informed
> when there is a problem and can take measures to cope with it.
>
> I hope people working on run-time environments will find ways
> to do better.

Re: [9fans] Google search of the day

[Brantley Coile]

>> (2) C, as well as many other PLs, has always had a problem in
>> that there is no clean, standard mechanism to handle the
>> situation in which a function invocation finds insufficient
>> stack remaining to complete the linkage (instance allocation).
>> This is especially problematic in memory-constrained apps such
>> as many embedded systems, when the algorithm is sufficiently
>> dynamic that it is impossible to predict the maximum nesting
>> depth.  At least with malloc failure, the program is informed
>> when there is a problem and can take measures to cope with it.
>>
>> I hope people working on run-time environments will find ways
>> to do better.

FORTRAN never had this problem.  Its memory needs were fixed at
compile time.  Neither did COBOL.  But then again, you couldn't write
recursive programs either; all locals were static storage class.  The
trade off to get recursion has been worth it and doesn't cause
problems actual use.  It wasn't a problem with Algol, PL/1, Pascal,
and C programs on very small machines.  Why should it be a problem
with today's memory sizes?

Brantley

Re: [9fans] Google search of the day

[Eris Discordia]

On Fri, 15 Feb 2008 14:56:57 -0000, Brantley Coile <brantley@coraid.com>
wrote:

> FORTRAN never had this problem.  Its memory needs were fixed at
> compile time.  Neither did COBOL.  But then again, you couldn't
> write recursive programs either; all locals were static storage
> class.  The trade off to get recursion has been worth it anddoesn't
> cause problems actual use.

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

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.

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

> It wasn't a problem with Algol, PL/1, Pascal, and C programs onvery
> small machines.  Why should it be a problem with today'smemory sizes?

I remember getting a lot of "out of stack" errors from QuickBASIC, Turbo C
and Borland C on MS-DOS. That was back when my computer had 8 MBs of RAM
(a Win32 PE today has a default stack size of 8 MBs!)

These days, stack overflows are most likely to cause problems by mingling
data (return addresses and/or parameters) with executable code. I suppose
segmentation mechanisms are there to precisely solve that problem. Never
curse the "segfault" again ;-)

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

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

[maht]

http://en.wikipedia.org/wiki/Stackless_Python

Is it the same sort of stack ?

It mentions Limbo as an inspiration

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.

Charles Moore said that you get about 40 items on the stack in a big
program iirc, though that was a few years ago.

Still, not much use to C based environments.

I'm hoping to get good enough at Forth to take one of these puppies for
a walk one day :
http://www.intellasys.net/index.php?option=com_content&task=view&id=35&Itemid=63

Re: [9fans] Google search of the day

[ron minnich]

On Fri, Feb 15, 2008 at 8:43 AM, maht <mattmobile@proweb.co.uk> wrote:

>  Charles Moore said that you get about 40 items on the stack in a big
>  program iirc, though that was a few years ago.
>

he musta never done  breakpoint in SunOS on a read ...

there was so much on the stack you couldn't display it on the screen.

ron

Re: [9fans] Google search of the day

[Iruata Souza]

On Fri, Feb 15, 2008 at 3:35 PM, ron minnich <rminnich@gmail.com> wrote:
> On Fri, Feb 15, 2008 at 8:43 AM, maht <mattmobile@proweb.co.uk> wrote:
>
>  >  Charles Moore said that you get about 40 items on the stack in a big
>  >  program iirc, though that was a few years ago.
>  >
>
>  he musta never done  breakpoint in SunOS on a read ...
>
>  there was so much on the stack you couldn't display it on the screen.
>
>  ron
>

that number^2 for some OS X stuff

iru

Re: [9fans] Google search of the day

[maht]

> he musta never done  breakpoint in SunOS on a read ...



I assume he meant while running Forth

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/

Re: [9fans] Google search of the day

[maht]

Forth doesn't use CALL it uses JMP

Similar Threaded Interpretive Languages run an inner loop that does this
pseudo code :
(from Threaded Interpretive Languages: Their Design and Implementation
by R. G. Loeliger)

COLON:
    PSH I -> RS
    WA -> I
    JMP NEXT
SEMI:
    POP RS -> I
NEXT:
    @I -> WA
    I += 2
RUN:
    @WA -> CA
    WA += 2
    CA -> PC

RS is the stack PC is the program counter, procedures JMP to NEXT or
SEMI when they are done
I is the indirection pointer, WA is the word address (the nomenclature
for procedure)
The 2s are there because this code assumes 16bit addressing, @ is
indirection
CA is the call address

so DUP is a word defined as (it copies the item on the top of the stack
back to the top of the stack
execute is a type marker, you can also have constant & colon

dup:
    execute
    POP SP -> A
    PUSH A -> SP
     PUSH A -> SP
   JMP NEXT


that's all very well but you then extend the assembler parts with new
words made from the WAs  (colon is the type marker for this) SEMI is
where it JMPs to at the end

moddiv:
    colon
    divmod
    swop
    semi



I wrote a TIL in AVR assembler last summer but I've waiting to go on
holiday this year so I can write some applications in it now I have a
dev board :>

Re: [9fans] Google search of the day

[Eris Discordia]

On Fri, 15 Feb 2008 19:05:28 -0000, maht <mattmobile@proweb.co.uk> wrote:

> Forth doesn't use CALL it uses JMP
>
> Similar Threaded Interpretive Languages run an inner loop that does this  
> pseudo code :
> (from Threaded Interpretive Languages: Their Design and Implementation  
> by R. G. Loeliger)
>
> COLON:
>     PSH I -> RS
>     WA -> I
>     JMP NEXT
> SEMI:
>     POP RS -> I
> NEXT:       @I -> WA
>     I += 2
> RUN:       @WA -> CA
>     WA += 2
>     CA -> PC
>

I know nothing about interpreted/interpretive languages but the above  
pseudo-code is, to my own surprise, quite readable to me.

The "indirection pointer" seems to funcionally match the (stack) base  
pointer on x86, with the word address equalling the stack pointer. So, the  
above says:

- Save the stack base address (PSH is PUSH, I assume).
- Set the stack base address to the beginning of the current frame.
- Jump to NEXT.
- Put the return address on top of the stack.
- Reserve space on the stack for one 16-bit (2-byte) address by  
incerementing the base pointer. On x86 one would decrement the base  
because the stack grows from higher addresses towards 0x0.
- Set the the call address to the beginning of the procedure.
- Set the program counter to the procedure ("call" it, in other words).

One strange thing is that code and (stack) data seem to both grow from 0x0  
towards 0xFFFF unlike x86 where the code sits in low address and the stack  
grows downwards. You have re-implemented the calling mechanism. You still  
have a call stack and the pertaining problems, but you have lost the  
convenience of a simple call instruction.

By the way, now I see what Erik Quanstrom meant by "alternative" calling  
conventions. Your pseudo-code is an example.

> that's all very well but you then extend the assembler parts with new  
> words made from the WAs  (colon is the type marker for this) SEMI is  
> where it JMPs to at the end
>
> moddiv:
>     colon
>     divmod
>     swop
>     semi

I am genuinely lost, do not understand a word of it.

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

Re: [9fans] Google search of the day

[Pietro Gagliardi]

Let's get back to humor. Here's from ReactOS 0.3.4's shutdown screen:

	The End ..... Try the sequel, hit the reset button right now!

	You can switch off your computer now

Re: [9fans] Google search of the day

[maht]

I think the stack direction is just for the pseudocode, the stack in my
implementation grew down, it depends  on what assembler primitives are
available I guess
>>
>>
>> moddiv:
>>     colon
>>     divmod
>>     swop
>>     semi
>
> I am genuinely lost, do not understand a word of it.


colon tells the inner loop that this is a set of other Words (addresses)
not machine instructions
so the loop will execute
divmod (which does division with modulous and leave the divsor,  mod on
the stack)
swop then reverses the order of the top two stack items
semi then jumps to semi to pop the next I before jumping to it

It gives you an interactive compiler without linking as you can add new
Words at runtime

:square dup *

would put
square :
    colon
    dup
   multiply
   semi

somewhere in memory (called the dictionary)

My version uses two stacks, one for args and one for addresses

for more analysis I suggest some online reading, I'm not deep enough
into either paradigm to offer suitable insights

Re: [9fans] Google search of the day

[Eris Discordia]

On Fri, 15 Feb 2008 20:49:06 -0000, maht <mattmobile@proweb.co.uk> wrote:

> for more analysis I suggest some online reading, I'm not deep enough
> into either paradigm to offer suitable insights
>

Wisely said. I really have to read a lot before I understand the ideas you
described. Only if the Finsler geometry course allows me ;-)

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

Re: [9fans] Google search of the day

[Eris Discordia]

On Thu, 14 Feb 2008 16:45:02 -0000, Douglas A. Gwyn <DAGwyn@null.net>
wrote:

> john@csplan9.rit.edu wrote:
>>         for (;;)
>>                 fork();
>
> In genuine UNIX(tm) systems, there is a per-user process limit,
> so eventually the fork requests start failing.  However, this
> program keeps trying to fork, so if you kill off some of the
> child processes it will spawn replacements.
>

That is not limited to UNIX proper. FreeBSD (and relatives, I suppose) all
have the /etc/login.conf where one can set limits on virtually all aspects
of user priviliges (cputime, filesize, datasize, stacksize, coredumpsize,
memoryuse, maxproc, openfiles, sbsize, etc) for arbitrary user classes. I
think it will be possible to kill the spawned children, because they are
all bound to have pids larger than a certain number.

I do not know if Linux has similar facilities. As for Plan 9, the book by
Francisco Ballesteros mentions a piece of code worse than the above and
points out that the only way to get rid of it would be to reboot the
system (which is quite as funny as the "bootsplash: silent mode," by the
way).

----snippet----
/* rabbits.c */

#include <u.h>
#include <libc.h>

void
main(int, char*[])
{
	// just like rabbits...
	while(fork())
		;
	exits(nil);
}
----snippet----

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

Re: [9fans] Google search of the day

[Fco. J. Ballesteros]

Children die soon in that one. This one is worse,
even the child starts spawning and so on...

while(1) fork();

>  ----snippet----
>  /* rabbits.c */
>
>  #include <u.h>
>  #include <libc.h>
>
>  void
>  main(int, char*[])
>  {
>  	// just like rabbits...
>  	while(fork())
>  		;
>  	exits(nil);
>  }
>  ----snippet----
>
>  --
>  Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] Google search of the day

[Eris Discordia]

On Thu, 14 Feb 2008 17:28:03 -0000, Fco. J. Ballesteros <nemo@lsub.org>
wrote:

> Children die soon in that one. This one is worse,
> even the child starts spawning and so on...
>
> while(1) fork();
>

I mistook your reference in the book and copy-pasted the code for the more
benign runaway process.

And, thanks for having written the book and made it available online. I
could not have begun learning Plan 9 without your book.

On Thu, 14 Feb 2008 17:51:59 -0000, Iruata Souza <iru.muzgo@gmail.com>
wrote:

> not if the pids are randomized as in OpenBSD.

Did not know that. On FreeBSD it seems like the pids tend to grow as the
number of processes grows. Had someone known the highest pid before the
runaway process was executed, they could have killed any process with a
higher pid.

On Thu, 14 Feb 2008 17:27:19 -0000, erik quanstrom <quanstro@coraid.com>
wrote:

> i don't see an easy systematic solution to this type of problem.

Some sort of rate control? Say, at most 5 processes per second. Of course,
that would also interfere with a busy webserver that spawns worker
threads/child processes for new connections. That could be solved by
running the webserver as a user belonging to the legitimately busy class.
Perhaps the question is, "what, other than human discretion,
differentiates a runaway process from a normal albeit busy one?" There is
very little evidence to distinguish a loop striving to compute the largest
prime number from a loop computing the factorial of 1234567890, an
altogether more useless task :-)

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

Re: [9fans] Google search of the day

[Patrick Kristiansen]

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

2008/2/14, Eris Discordia <eris.discordia@gmail.com>:
>
> There is
> very little evidence to distinguish a loop striving to compute the largest
> prime number from a loop computing the factorial of 1234567890, an
> altogether more useless task :-)


I would say that trying to compute THE largest prime number would be quite
pointless.

-Patrick Kristiansen.

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

Re: [9fans] Google search of the day

[Eris Discordia]

On Thu, 14 Feb 2008 20:30:22 -0000, Patrick Kristiansen
<patrick.kasserer@gmail.com> wrote:

> 2008/2/14, Eris Discordia <eris.discordia@gmail.com>:
>>
>> There is
>> very little evidence to distinguish a loop striving to compute the
>> largest
>> prime number from a loop computing the factorial of 1234567890, an
>> altogether more useless task :-)
>
>
> I would say that trying to compute THE largest prime number would be
> quite
> pointless.
>
> -Patrick Kristiansen.

These days hardly anyone is ignorant enough to not know there are
infinitely many prime numbers. I was kidding.

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

Re: [9fans] Google search of the day

[Pietro Gagliardi]

Here's what I think is the best solution: statically allocate the
maximum number of tasks per process:

	struct JobControlBlock { /* the name my OS uses for the info field
of a process (job) */
		Task *mainTask; /* task == thread */
		Task *jobTasks[400]; /* pointers to entry in an array of statically
allocated tasks */
	};

A Task runs a function; it does not continue executing at the current
point. Returning from that function halts the task. Returning from
the main task halts all tasks.

Now a SpawnTask() (fork()) can only be done to create up to 400 tasks
with the exception of the main task.

Re: [9fans] Google search of the day

[Eris Discordia]

On Thu, 14 Feb 2008 22:09:04 -0000, Pietro Gagliardi <pietro10@mac.com>  
wrote:

> Here's what I think is the best solution: statically allocate the  
> maximum number of tasks per process:
>
> 	struct JobControlBlock { /* the name my OS uses for the info field of a  
> process (job) */
> 		Task *mainTask; /* task == thread */
> 		Task *jobTasks[400]; /* pointers to entry in an array of statically  
> allocated tasks */
> 	};
>
> A Task runs a function; it does not continue executing at the current  
> point. Returning from that function halts the task. Returning from the  
> main task halts all tasks.
>

That parallels Microsoft NT's concept of threads (aka, lightweight  
processes):

//ThreadProc is the "function" the thread runs
hThread = CreateThread (&security_attributes, dwStackSize, ThreadProc,  
pParam, dwFlags, &idThread);

Which is rather old, by the way. The same concept re-surfaced later on in  
.NET as the Thread and ThreadPool classes in System.Threading namespace.

Sidenote: despite the negative hype, Windows programming is jolly merry.

> Now a SpawnTask() (fork()) can only be done to create up to 400 tasks  
> with the exception of the main task.
>

As Erik Quanstrom pointed out, setting a limit for the total number of  
processes/tasks/threads would create another vulnerability. That is,  
inability to create any more processes because some  
malicious/poorly-written process is consuming all the quota.

I am wondering which magical property of the number 400 has made it  
suitable as the limit to the number of tasks. Four hundred tasks may be  
amenable on your platform but wreak havoc on somebody else's poor old PC.

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

Re: [9fans] Google search of the day

[Iruata Souza]

On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> I  think it will be possible to kill the spawned children, because they are
>  all bound to have pids larger than a certain number.
>

not if the pids are randomized as in OpenBSD.

iru

Re: [9fans] Google search of the day

[sqweek]

On Fri, Feb 15, 2008 at 2:51 AM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia
>  <eris.discordia@gmail.com> wrote:
>  > I  think it will be possible to kill the spawned children, because they are
>  >  all bound to have pids larger than a certain number.
>
>  not if the pids are randomized as in OpenBSD.

 Easy to take care of in unix, just don't kill anything until you've
suspended all the fork happy procs. Is there a fork analog in plan 9?

-sqweek, who should just read proc(3) but since he's commenting anyway...

Re: [9fans] Google search of the day

[Douglas A. Gwyn]

sqweek wrote:
> Is there a fork analog in plan 9?

rfork, which is more general in that the program can specify
in more detail which resources are to be shared and which are
to be copied.

Re: [9fans] Google search of the day

[Gorka Guardiola]

On Feb 18, 2008 10:48 AM, Douglas A. Gwyn <DAGwyn@null.net> wrote:
> sqweek wrote:
> > Is there a fork analog in plan 9?
>
> rfork, which is more general in that the program can specify
> in more detail which resources are to be shared and which are
> to be copied.
>

Or even better, fork(2) which is a library function enveloping rfork(2):

int
fork(void)
{
         return rfork(RFPROC|RFFDG|RFREND);
}

--
- curiosity sKilled the cat

Re: [9fans] Google search of the day

[sqweek]

On Feb 18, 2008 6:48 PM, Douglas A. Gwyn <DAGwyn@null.net> wrote:
> sqweek wrote:
> > Is there a fork analog in plan 9?
>
> rfork, which is more general in that the program can specify
> in more detail which resources are to be shared and which are
> to be copied.

 Er, right. I knew that, I meant to ask if there was a SIGSTOP analog.
 I've since glanced at proc(3) which told me "echo stop >/proc/XXXX/ctl".
-sqweek

[9fans] quote of the day

[erik quanstrom]

"Do not spend too much time trying to figure out why this math works.
The basis for the computation is complicated; the important point is
that this is how Microsoft operating systems do it, and it works.  Note,
however, that this math does not work perfectly."
	- Microsoft EFI FAT32 File System Specification, p. 32

- erik

Re: [9fans] quote of the day

[Patrick Kelly]

>-----Original Message-----
>From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of
erik quanstrom
>Sent: Friday, December 25, 2009 4:43 AM
>To: 9fans@9fans.net
>Subject: [9fans] quote of the day

>"Do not spend too much time trying to figure out why this math works.
>The basis for the computation is complicated; the important point is that
this is how Microsoft operating systems do it, and it works.  Note, however,
that this math does not work perfectly."
>	- Microsoft EFI FAT32 File System Specification, p. 32
-_-`	Oh boy...

>- erik

Re: [9fans] quote of the day

[Jamie Gavahan]

On Fri, Dec 25, 2009 at 03:43, erik quanstrom <quanstro@quanstro.net> wrote:
> "Do not spend too much time trying to figure out why this math works.
> The basis for the computation is complicated; the important point is
> that this is how Microsoft operating systems do it, and it works.  Note,
> however, that this math does not work perfectly."
>        - Microsoft EFI FAT32 File System Specification, p. 32

Even better is that it is referred to as "a clever piece of arithmetic" two
pages earlier.

- jamie

Re: [9fans] quote of the day

[Bruce Ellis]

it doesn't work, it doesn't have to, and it's secret!

perfect documentation for shitware.

brucee

On 12/26/09, Jamie Gavahan <redpike@gmail.com> wrote:
> On Fri, Dec 25, 2009 at 03:43, erik quanstrom <quanstro@quanstro.net> wrote:
> > "Do not spend too much time trying to figure out why this math works.
> > The basis for the computation is complicated; the important point is
> > that this is how Microsoft operating systems do it, and it works.  Note,
> > however, that this math does not work perfectly."
> >        - Microsoft EFI FAT32 File System Specification, p. 32
>
> Even better is that it is referred to as "a clever piece of arithmetic" two
> pages earlier.
>
> - jamie
>
>

Re: [9fans] quote of the day

[Akshat Kumar]

So... mm...

Where's the working AMD 64 port again?


oh, ok
ak

On Sat, Dec 26, 2009 at 6:50 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> it doesn't work, it doesn't have to, and it's secret!
>
> perfect documentation for shitware.
>
> brucee
>

Re: [9fans] quote of the day

[Bruce Ellis]

answer in one.

On 12/26/09, Akshat Kumar <akumar@mail.nanosouffle.net> wrote:
> So... mm...
>
> Where's the working AMD 64 port again?
>
>
> oh, ok
> ak
>
> On Sat, Dec 26, 2009 at 6:50 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> > it doesn't work, it doesn't have to, and it's secret!
> >
> > perfect documentation for shitware.
> >
> > brucee
> >
>
>