[9fans] bug in asm.ps

[9fans] bug in asm.ps

[Gorka guardiola]

If I have undertood correctly SP points to the last automatic in the top of
the stack, so 4(SP) is the last-1 automatic and so on, so, the document
"A Manual for the Plan 9 assembler" is wrong, at least for 8c/8l.

Am I right?.
--
- curiosity sKilled the cat

Re: [9fans] bug in asm.ps

[Brantley Coile]

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

SP doesn't point to the last automatic on the stack.
Not only is the automatics on the local stack, but also
temporaries, like the ones to hold parameters to a function.
If you call any functions 4(SP) is the second parameter to functions.

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

From: "Gorka guardiola" <paurea@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: [9fans] bug in asm.ps
Date: Mon, 6 Mar 2006 16:12:34 +0100
Message-ID: <599f06db0603060712l2fc621f1jbeaa3ad41d709d96@mail.gmail.com>

If I have undertood correctly SP points to the last automatic in the top of
the stack, so 4(SP) is the last-1 automatic and so on, so, the document
"A Manual for the Plan 9 assembler" is wrong, at least for 8c/8l.

Am I right?.
--
- curiosity sKilled the cat

Re: [9fans] bug in asm.ps

[Gorka guardiola]

Ok, but what I meant is that the automatics are upside down growing from n
to 0 as the memory grows. Of course if you call any functions, the SP points
to the last space left for their arguments. As far as I understand if you dont
call any functions, 0(SP) is the last automatic. If you dont have any
automatics, SP points to the return PC. If you call any functions there is space
for their args (probably for the args of the functions with the
biggest number of args) and SP is pointing to the last space which
will be the first arg, because
they gro from 0 to n as the memory grows.

On 3/6/06, Brantley Coile <brantley@coraid.com> wrote:
> SP doesn't point to the last automatic on the stack.
> Not only is the automatics on the local stack, but also
> temporaries, like the ones to hold parameters to a function.
> If you call any functions 4(SP) is the second parameter to functions.
>
>


--
- curiosity sKilled the cat

Re: [9fans] bug in asm.ps

[Brantley Coile]

Oh, I understand now.  You are correct.  Asm.ps is wrong.

> Ok, but what I meant is that the automatics are upside down growing from n
> to 0 as the memory grows. Of course if you call any functions, the SP points
> to the last space left for their arguments. As far as I understand if you dont
> call any functions, 0(SP) is the last automatic. If you dont have any
> automatics, SP points to the return PC. If you call any functions there is space
> for their args (probably for the args of the functions with the
> biggest number of args) and SP is pointing to the last space which
> will be the first arg, because
> they gro from 0 to n as the memory grows.
>
> On 3/6/06, Brantley Coile <brantley@coraid.com> wrote:
>> SP doesn't point to the last automatic on the stack.
>> Not only is the automatics on the local stack, but also
>> temporaries, like the ones to hold parameters to a function.
>> If you call any functions 4(SP) is the second parameter to functions.
>>
>>

Re: [9fans] bug in asm.ps

[Russ Cox]

> Oh, I understand now.  You are correct.  Asm.ps is wrong.

What exactly do you think is wrong?
(And keep in mind that page 1 is explicitly
marked as a discussion of 2a.)

Russ

Re: [9fans] bug in asm.ps

[Brantley Coile]

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

I've never made a mistake... I once thought I had, but was wrong.

I forgot that it was talking about the '020.
That context thing. :)

I kind of like the way that 8c allocates them.  That means that
I could dump &first to the &last and see the local stack frame.
It struck me years ago that the stack frame was just an implied
structure.

Might be mentioned in the 8a section, though.

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

From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug in asm.ps
Date: Mon, 6 Mar 2006 10:53:55 -0500
Message-ID: <fa27b3307cfc3f25dc2c342741d61af5@swtch.com>

> Oh, I understand now.  You are correct.  Asm.ps is wrong.

What exactly do you think is wrong?
(And keep in mind that page 1 is explicitly
marked as a discussion of 2a.)

Russ

Re: [9fans] bug in asm.ps

[Gorka guardiola]

Is it different in 2a?. Anyway, I thought it first discusses 2a and
then there are
the differences with it in the next pages.  The i386 section doesnt
say anything...

On 3/6/06, Russ Cox <rsc@swtch.com> wrote:
> > Oh, I understand now.  You are correct.  Asm.ps is wrong.
>
> What exactly do you think is wrong?
> (And keep in mind that page 1 is explicitly
> marked as a discussion of 2a.)

--
- curiosity sKilled the cat

Re: [9fans] bug in asm.ps

[Russ Cox]

I still don't know what you think is wrong.
Are you referring to the order in which stack
variables are allocated in the stack frame?
(I thought you were referring to the placement
of temporaries to hold function call parameters.)
All the compilers allocate their stack frames the
same way, as far as I can tell.  But I don't see
asm.ps making claims about what the correspondence
between assembly and C is.  First and last
depend on your point of view.

Russ

Re: [9fans] bug in asm.ps

[Brantley Coile]

Then I don't know what the word `automatic' means for an assembler.

> I still don't know what you think is wrong.
> Are you referring to the order in which stack
> variables are allocated in the stack frame?
> (I thought you were referring to the placement
> of temporaries to hold function call parameters.)
> All the compilers allocate their stack frames the
> same way, as far as I can tell.  But I don't see
> asm.ps making claims about what the correspondence
> between assembly and C is.  First and last
> depend on your point of view.
>
> Russ

Re: [9fans] bug in asm.ps

[Russ Cox]

> Then I don't know what the word `automatic' means for an assembler.

Then I don't know what the phrase "first automatic" means for a C compiler.

Russ

Re: [9fans] bug in asm.ps

[Gorka guardiola]

I dont want to enter weird discussions. When I read asm.ps it seems to me
it implies that the automatics are ordered  local first, local n as the
memory grows. It says 0(SP) is the first, 4(SP) is the second and so on.
For me the first is the first declared in C. First as in 1st.
This is wrong taking all this assumptions.

On 3/6/06, Russ Cox <rsc@swtch.com> wrote:
> > Then I don't know what the word `automatic' means for an assembler.
>
> Then I don't know what the phrase "first automatic" means for a C compiler.
>
> Russ
>
>


--
- curiosity sKilled the cat

Re: [9fans] bug in asm.ps

[Charles Forsyth]

> For me the first is the first declared in C. First as in 1st.
> This is wrong taking all this assumptions.

there is no guarantee in C that variables outside structs
are allocated in order of declaration, and indeed, storage
might not be allocated at all if entirely contained in a register.
for instance, in the plan 9 implementation, external values are
allocated out of order by several ?l, allocating bigger things last,
to give smaller offsets from SB for other values (when SB is a real
register).  automatic variables might or might not be allocated a register.

asm.ms describes things from the point of view of the loader, or
object code, not a compiler, but what it doesn't say (i think) is what
the negative offsets mean (they index from the other end of the space
used for automatic variables, allowing for pushes and pops where those exist,
and a few other peculiar constructions).