Re: [9fans] assembly syntax in plan 9

Re: [9fans] assembly syntax in plan 9

[Alexander Kapshuk]

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

i have a question about putting things on the stack for x86 arch under plan
9...

under unix/linux, when defining a function, i would:
(1). push the address the base pointer is pointing to prior to this
function being called, onto the stack; e.g. pushl %ebp
(2). then i would have the base pointer point to the current stack pointer;
e.g. movl %esp, %ebp
(3). then i would allocate space on the stack for local variables, if any;
e.g. subl $n, %esp;
(4). then follows the function body;
to return from the function i would:
(1). restore the stack pointer; e.g. movl %ebp, %esp;
(2). restore the base pointer, e.g. popl %ebp;
(3). then return to the calling function;

i searched the 9fans archives for posts on assembly programming under plan
9; found some bits and pieces; e.g. in one of the posts it was mentioned
that BP is a general purpose register, not the base pointer; and that FP is
what ebp is under unix/linux;

in the paper for the plan 9 assembler, it says that there are three
registers available to manipulate the stack, FP, SP, and TOS; would the
following comparison stand true then?
plan9    unix/linux
-------     -------------
FP        EBP
SP        -4(%EBP)...-n(%EBP) /* local variables */
TOS     ESP

thanks;

sasha kapshuk

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

Re: [9fans] assembly syntax in plan 9

[Charles Forsyth]

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

You should read /sys/doc/asm.pdf first.
careful: TOS is only for 68k. nothing else defines or uses it.

Plan 9 doesn't use a base pointer, because everything can be addressed
relative to the stack pointer,
and the loader keeps track of the SP level. thus FP is a virtual register,
that the loader implements
by replacing offsets relative to it by the current appropriate offset from
the hardware stack pointer register (whatever
that might be on a given platform). That's esp on the x86. the TEXT
directive specifies the space a function
requires for its stack frame, and the loader then adds appropriate code at
start and end to provide it.
0(FP) is the first argument, 4(FP) is the second, and so on. 0(SP) is the
bottom of the current frame,
and 0(SP), 4(SP) etc are referenced to build the arguments for outgoing
calls (but that space must
be accounted for in the TEXT directive).

(it's probably not very different in effect from -fno-frame-pointer or
whatever it is for gcc,
which also doesn't use ebp except that is implemented entirely by the
compiler.)

On 16 January 2012 12:30, Alexander Kapshuk <alexander.kapshuk@gmail.com>wrote:

> i have a question about putting things on the stack for x86 arch under
> plan 9...
>
> under unix/linux, when defining a function, i would:
> (1). push the address the base pointer is pointing to prior to this
> function being called, onto the stack; e.g. pushl %ebp
> (2). then i would have the base pointer point to the current stack
> pointer; e.g. movl %esp, %ebp
> (3). then i would allocate space on the stack for local variables, if any;
> e.g. subl $n, %esp;
> (4). then follows the function body;
> to return from the function i would:
> (1). restore the stack pointer; e.g. movl %ebp, %esp;
> (2). restore the base pointer, e.g. popl %ebp;
> (3). then return to the calling function;
>
> i searched the 9fans archives for posts on assembly programming under plan
> 9; found some bits and pieces; e.g. in one of the posts it was mentioned
> that BP is a general purpose register, not the base pointer; and that FP is
> what ebp is under unix/linux;
>
> in the paper for the plan 9 assembler, it says that there are three
> registers available to manipulate the stack, FP, SP, and TOS; would the
> following comparison stand true then?
> plan9    unix/linux
> -------     -------------
> FP        EBP
> SP        -4(%EBP)...-n(%EBP) /* local variables */
> TOS     ESP
>
> thanks;
>
> sasha kapshuk
>
>

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

Re: [9fans] assembly syntax in plan 9

[Alexander Kapshuk]

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

On Mon, Jan 16, 2012 at 3:08 PM, Charles Forsyth
<charles.forsyth@gmail.com>wrote:

>
> You should read /sys/doc/asm.pdf first.
> careful: TOS is only for 68k. nothing else defines or uses it.
>
> Plan 9 doesn't use a base pointer, because everything can be addressed
> relative to the stack pointer,
> and the loader keeps track of the SP level. thus FP is a virtual register,
> that the loader implements
> by replacing offsets relative to it by the current appropriate offset from
> the hardware stack pointer register (whatever
> that might be on a given platform). That's esp on the x86. the TEXT
> directive specifies the space a function
> requires for its stack frame, and the loader then adds appropriate code at
> start and end to provide it.
> 0(FP) is the first argument, 4(FP) is the second, and so on. 0(SP) is the
> bottom of the current frame,
> and 0(SP), 4(SP) etc are referenced to build the arguments for outgoing
> calls (but that space must
> be accounted for in the TEXT directive).
>
> (it's probably not very different in effect from -fno-frame-pointer or
> whatever it is for gcc,
> which also doesn't use ebp except that is implemented entirely by the
> compiler.)
>
> On 16 January 2012 12:30, Alexander Kapshuk <alexander.kapshuk@gmail.com>wrote:
>
>> i have a question about putting things on the stack for x86 arch under
>> plan 9...
>>
>> under unix/linux, when defining a function, i would:
>> (1). push the address the base pointer is pointing to prior to this
>> function being called, onto the stack; e.g. pushl %ebp
>> (2). then i would have the base pointer point to the current stack
>> pointer; e.g. movl %esp, %ebp
>> (3). then i would allocate space on the stack for local variables, if
>> any; e.g. subl $n, %esp;
>> (4). then follows the function body;
>> to return from the function i would:
>> (1). restore the stack pointer; e.g. movl %ebp, %esp;
>> (2). restore the base pointer, e.g. popl %ebp;
>> (3). then return to the calling function;
>>
>> i searched the 9fans archives for posts on assembly programming under
>> plan 9; found some bits and pieces; e.g. in one of the posts it was
>> mentioned that BP is a general purpose register, not the base pointer; and
>> that FP is what ebp is under unix/linux;
>>
>> in the paper for the plan 9 assembler, it says that there are three
>> registers available to manipulate the stack, FP, SP, and TOS; would the
>> following comparison stand true then?
>> plan9    unix/linux
>> -------     -------------
>> FP        EBP
>> SP        -4(%EBP)...-n(%EBP) /* local variables */
>> TOS     ESP
>>
>> thanks;
>>
>> sasha kapshuk
>>
>>
>
thanks;

i'll look into that;

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

Re: [9fans] assembly syntax in plan 9

[Bakul Shah]

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

A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer.

On Jan 16, 2012, at 5:08 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> 
> You should read /sys/doc/asm.pdf first. 
> careful: TOS is only for 68k. nothing else defines or uses it.
> 
> Plan 9 doesn't use a base pointer, because everything can be addressed relative to the stack pointer,
> and the loader keeps track of the SP level. thus FP is a virtual register, that the loader implements
> by replacing offsets relative to it by the current appropriate offset from the hardware stack pointer register (whatever
> that might be on a given platform). That's esp on the x86. the TEXT directive specifies the space a function
> requires for its stack frame, and the loader then adds appropriate code at start and end to provide it.
> 0(FP) is the first argument, 4(FP) is the second, and so on. 0(SP) is the bottom of the current frame,
> and 0(SP), 4(SP) etc are referenced to build the arguments for outgoing calls (but that space must
> be accounted for in the TEXT directive).
> 
> (it's probably not very different in effect from -fno-frame-pointer or whatever it is for gcc,
> which also doesn't use ebp except that is implemented entirely by the compiler.)
> 
> On 16 January 2012 12:30, Alexander Kapshuk <alexander.kapshuk@gmail.com> wrote:
> i have a question about putting things on the stack for x86 arch under plan 9...
> 
> under unix/linux, when defining a function, i would:
> (1). push the address the base pointer is pointing to prior to this function being called, onto the stack; e.g. pushl %ebp
> (2). then i would have the base pointer point to the current stack pointer; e.g. movl %esp, %ebp
> (3). then i would allocate space on the stack for local variables, if any; e.g. subl $n, %esp;
> (4). then follows the function body;
> to return from the function i would:
> (1). restore the stack pointer; e.g. movl %ebp, %esp;
> (2). restore the base pointer, e.g. popl %ebp;
> (3). then return to the calling function;
> 
> i searched the 9fans archives for posts on assembly programming under plan 9; found some bits and pieces; e.g. in one of the posts it was mentioned that BP is a general purpose register, not the base pointer; and that FP is what ebp is under unix/linux;
> 
> in the paper for the plan 9 assembler, it says that there are three registers available to manipulate the stack, FP, SP, and TOS; would the following comparison stand true then?
> plan9    unix/linux
> -------     -------------
> FP        EBP
> SP        -4(%EBP)...-n(%EBP) /* local variables */
> TOS     ESP
> 
> thanks;
> 
> sasha kapshuk
> 
> 

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

Re: [9fans] assembly syntax in plan 9

[Joel C. Salomon]

On 01/16/2012 08:08 AM, Charles Forsyth wrote:
> Plan 9 doesn't use a base pointer, because everything can be addressed
> relative to the stack pointer, and the loader keeps track of the SP
> level. thus FP is a virtual register, that the loader implements by
> replacing offsets relative to it by the current appropriate offset from
> the hardware stack pointer register (whatever that might be on a given
> platform). That's esp on the x86. the TEXT directive specifies the
> space a function requires for its stack frame, and the loader then adds
> appropriate code at start and end to provide it. 0(FP) is the first
> argument, 4(FP) is the second, and so on. 0(SP) is the bottom of the
> current frame, and 0(SP), 4(SP) etc are referenced to build the
> arguments for outgoing calls (but that space must be accounted for in
> the TEXT directive).

This would make it difficult to implement C99's variable-length
(actually, run-time-determined--length) arrays.  The best compiler-only
change I can think of would be to define a hidden variable `size_t
__size_of_all_vlas`, and add code to adjust SP by that amount before &
after each function call.

[Or we could just skip C99, and make the compiler C11-compliant by
pre-defining __STDC_NO_VLA__. ☺]

> (it's probably not very different in effect from -fno-frame-pointer or
> whatever it is for gcc, which also doesn't use ebp except that is
> implemented entirely by the compiler.)

Google turns up <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39337>,
indicating that GCC had issues combining VLAs and -fomit-frame-pointer;
I don't know how they managed the combination.

--Joel

Re: [9fans] assembly syntax in plan 9

[erik quanstrom]

> [Or we could just skip C99, and make the compiler C11-compliant by
> pre-defining __STDC_NO_VLA__. ☺]

i think the the compilers have taken c99 under advisement.  see
/sys/src/cmd/cc/c99.  most reasonable features of c99 have
been implemented. 
of the remaining entries in the "Not Done (yet?)" section, 9, 19 and
and 25 stand out to me as the most worth implementing.  (although proper
implementation of 25 is likely to break some things.) other folks might
be more excited about _Imaginary, _Complex and
_Surelythisisobscureenoughtonotbreakstuff.

but otoh, we seem to have bigger fish to fry.

- erik

Re: [9fans] assembly syntax in plan 9

[Charles Forsyth]

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

Not really. One just implements them. For instance, there's no requirement
for all function bodies to use the same scheme.
The unusual bit is that you need to tell the loader what's going on, but
there are still a few bits free for that.
I haven't looked at the details here, but I've had to implement this
before, for Ada, in a different environment,
and don't remember it being too hard, compared to a big list of much harder
things.

On 16 January 2012 16:07, Joel C. Salomon <joelcsalomon@gmail.com> wrote:

> This would make it difficult to implement C99's variable-length
> (actually, run-time-determined--length) arrays.
>

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

Re: [9fans] assembly syntax in plan 9

[Bakul Shah]

On Jan 16, 2012, at 8:07 AM, "Joel C. Salomon" <joelcsalomon@gmail.com> wrote:
> This would make it difficult to implement C99's variable-length
> (actually, run-time-determined--length) arrays.  The best compiler-only
> change I can think of would be to define a hidden variable `size_t
> __size_of_all_vlas`, and add code to adjust SP by that amount before &
> after each function call.

Length can be derived from user input, or diff. arrays can be allocated in diff. branches of switch or if stmt. so your trick won't always work.

> Google turns up <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39337>,
> indicating that GCC had issues combining VLAs and -fomit-frame-pointer;
> I don't know how they managed the combination.

Must use a frame pointer in any function that has VLAs and must save it before calling another function from it. 

Re: [9fans] assembly syntax in plan 9

[Comeau At9Fans]

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

On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:

> A frame pointer is needed for C99's variable length arrays but not
> otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x.
> gcc has to do the right thing even with -fno-frame-pointer.
>

What we do in problematic cases with Comeau is to generate code to arrange
for the allocation of the VLA on the heap.  I'm not saying this is perfect,
but at least it gets the feature implementable and up and running as "a
portable implementation" versus perhaps not being able to implement it at
all on some platforms.

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

Re: [9fans] assembly syntax in plan 9

[Bakul Shah]

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

How do you deal with longjmp?

On Jan 16, 2012, at 10:51 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:

> On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:
> A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer.
> 
> What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap.  I'm not saying this is perfect, but at least it gets the feature implementable and up and running as "a portable implementation" versus perhaps not being able to implement it at all on some platforms.

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

Re: [9fans] assembly syntax in plan 9

[Charles Forsyth]

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

They are compiling C++ which has language-visible exception handling
instead.

On 16 January 2012 19:03, Bakul Shah <bakul@bitblocks.com> wrote:

> How do you deal with longjmp?
>
>
> On Jan 16, 2012, at 10:51 AM, Comeau At9Fans <comeauat9fans@gmail.com>
> wrote:
>
> On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>
>> A frame pointer is needed for C99's variable length arrays but not
>> otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x.
>> gcc has to do the right thing even with -fno-frame-pointer.
>>
>
> What we do in problematic cases with Comeau is to generate code to arrange
> for the allocation of the VLA on the heap.  I'm not saying this is perfect,
> but at least it gets the feature implementable and up and running as "a
> portable implementation" versus perhaps not being able to implement it at
> all on some platforms.
>
>

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

Re: [9fans] assembly syntax in plan 9

[erik quanstrom]

On Mon Jan 16 14:40:41 EST 2012, charles.forsyth@gmail.com wrote:

> They are compiling C++ which has language-visible exception handling
> instead.
>
> On 16 January 2012 19:03, Bakul Shah <bakul@bitblocks.com> wrote:
>
> > How do you deal with longjmp?
> >

i thought this wasn't entirely supported, see the "limitations" section.
http://drdobbs.com/184401468

(i had a better reference, but can't find it anymore.)

- erik

Re: [9fans] assembly syntax in plan 9

[Joel C. Salomon]

On 01/16/2012 02:03 PM, Bakul Shah wrote:
> On Jan 16, 2012, at 10:51 AM, Greg Comeau <comeauat9fans@gmail.com> wrote:
>> What we do in problematic cases with Comeau is to generate code to
>> arrange for the allocation of the VLA on the heap.  I'm not saying
>> this is perfect, but at least it gets the feature implementable and up
>> and running as "a portable implementation" versus perhaps not being
>> able to implement it at all on some platforms.
>
> How do you deal with longjmp?

I recall reading the source for a (mostly-) portable alloca() that
checked where on the call-stack is was invoked from and released memory
for any alloca() invocation from lower on the stack.  (The allocations
themselves were on the heap.)

--Joel

Re: [9fans] assembly syntax in plan 9

[Bakul Shah]

On Mon, 16 Jan 2012 15:11:24 EST "Joel C. Salomon" <joelcsalomon@gmail.com>  wrote:
> On 01/16/2012 02:03 PM, Bakul Shah wrote:
> > On Jan 16, 2012, at 10:51 AM, Greg Comeau <comeauat9fans@gmail.com> wrote:
> >> What we do in problematic cases with Comeau is to generate code to
> >> arrange for the allocation of the VLA on the heap.  I'm not saying
> >> this is perfect, but at least it gets the feature implementable and up
> >> and running as "a portable implementation" versus perhaps not being
> >> able to implement it at all on some platforms.
> >
> > How do you deal with longjmp?
>
> I recall reading the source for a (mostly-) portable alloca() that
> checked where on the call-stack is was invoked from and released memory
> for any alloca() invocation from lower on the stack.  (The allocations
> themselves were on the heap.)

You are probably referring to Doug Gwyn's portable alloca().
It relies on a static var to keep track of malloced alloca
blocks. At first I thought it won't work in presence of
threads but I guess if you used thread local storage for this,
alloca() might be made to work but it is pretty bletcherous!

Here's what Gwyn had to say about alloca() later....  [From
https://www.securecoding.cert.org/confluence/display/seccode/08.+Memory+Management+(MEM)

    Douglas A. Gwyn

    Never use alloca.  (See my comments in the Gnu source for
    alloca.)  Under C99, you can use VLAs.  Cince they require
    a FIFO lifetime model, neither is as general as dynamic
    allocation.

Funny that he recommends using VLAs instead of alloca()!

Re: [9fans] assembly syntax in plan 9

[Comeau At9Fans]

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

On Mon, Jan 16, 2012 at 2:03 PM, Bakul Shah <bakul@bitblocks.com> wrote:

> How do you deal with longjmp?
>

I don't have it in front of me, but I do seem to recall the Standard allows
that the VLA might still be around though, believe it has an example with
said, for better or worse...  Anyway, at some point we're able to detect
that the previous VLA(s) is no longer active and "toss" them.


> On Jan 16, 2012, at 10:51 AM, Comeau At9Fans <comeauat9fans@gmail.com>
> wrote:
>
> On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>
>> A frame pointer is needed for C99's variable length arrays but not
>> otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x.
>> gcc has to do the right thing even with -fno-frame-pointer.
>>
>
> What we do in problematic cases with Comeau is to generate code to arrange
> for the allocation of the VLA on the heap.  I'm not saying this is perfect,
> but at least it gets the feature implementable and up and running as "a
> portable implementation" versus perhaps not being able to implement it at
> all on some platforms.
>
> --
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

Re: [9fans] assembly syntax in plan 9

[Comeau At9Fans]

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

We do allow VLAs in C++ mode as well, but currently keep them separate from
EH.

On Mon, Jan 16, 2012 at 2:39 PM, Charles Forsyth
<charles.forsyth@gmail.com>wrote:

> They are compiling C++ which has language-visible exception handling
> instead.
>
>
> On 16 January 2012 19:03, Bakul Shah <bakul@bitblocks.com> wrote:
>
>> How do you deal with longjmp?
>>
>>
>> On Jan 16, 2012, at 10:51 AM, Comeau At9Fans <comeauat9fans@gmail.com>
>> wrote:
>>
>> On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>>
>>> A frame pointer is needed for C99's variable length arrays but not
>>> otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x.
>>> gcc has to do the right thing even with -fno-frame-pointer.
>>>
>>
>> What we do in problematic cases with Comeau is to generate code to
>> arrange for the allocation of the VLA on the heap.  I'm not saying this is
>> perfect, but at least it gets the feature implementable and up and running
>> as "a portable implementation" versus perhaps not being able to implement
>> it at all on some platforms.
>>
>>
>


--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

Re: [9fans] assembly syntax in plan 9

[Comeau At9Fans]

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

On Mon, Jan 16, 2012 at 2:49 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Mon Jan 16 14:40:41 EST 2012, charles.forsyth@gmail.com wrote:
>
> > They are compiling C++ which has language-visible exception handling
> > instead.
> >
> > On 16 January 2012 19:03, Bakul Shah <bakul@bitblocks.com> wrote:
> >
> > > How do you deal with longjmp?
> > >
>
> i thought this wasn't entirely supported, see the "limitations" section.
> http://drdobbs.com/184401468
>
> (i had a better reference, but can't find it anymore.)


My recollection is that that paragraph correctly reflects the situation.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

Re: [9fans] assembly syntax in plan 9

[Comeau At9Fans]

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

On Mon, Jan 16, 2012 at 3:11 PM, Joel C. Salomon <joelcsalomon@gmail.com>wrote:

> On 01/16/2012 02:03 PM, Bakul Shah wrote:
> > On Jan 16, 2012, at 10:51 AM, Greg Comeau <comeauat9fans@gmail.com>
> wrote:
> >> What we do in problematic cases with Comeau is to generate code to
> >> arrange for the allocation of the VLA on the heap.  I'm not saying
> >> this is perfect, but at least it gets the feature implementable and up
> >> and running as "a portable implementation" versus perhaps not being
> >> able to implement it at all on some platforms.
> >
> > How do you deal with longjmp?
>
> I recall reading the source for a (mostly-) portable alloca() that
> checked where on the call-stack is was invoked from and released memory
> for any alloca() invocation from lower on the stack.  (The allocations
> themselves were on the heap.)


We do some analogous book keeping as well.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

Re: [9fans] assembly syntax in plan 9

[Bakul Shah]

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

On Jan 17, 2012, at 11:21 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:

> On Mon, Jan 16, 2012 at 2:03 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> How do you deal with longjmp?
> 
> I don't have it in front of me, but I do seem to recall the Standard allows that the VLA might still be around though, believe it has an example with said, for better or worse...

Do you have a reference?

> On Jan 16, 2012, at 10:51 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
>> On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>> A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer.
>> 
>> What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap.  I'm not saying this is perfect, but at least it gets the feature implementable and up and running as "a portable implementation" versus perhaps not being able to implement it at all on some platforms.

Seems to me if you can port C, you can use a FP to implement VLAs without alloca games and more efficiently. You can always store the FP in stack local memory if out of registers.

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

Re: [9fans] assembly syntax in plan 9

[Comeau At9Fans]

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

On Wed, Jan 18, 2012 at 12:48 PM, Bakul Shah <bakul@bitblocks.com> wrote:

> On Jan 17, 2012, at 11:21 AM, Comeau At9Fans <comeauat9fans@gmail.com>
> wrote:
> On Mon, Jan 16, 2012 at 2:03 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>
> How do you deal with longjmp?
>>
>
> I don't have it in front of me, but I do seem to recall the Standard
> allows that the VLA might still be around though, believe it has an example
> with said, for better or worse...
>
>
> Do you have a reference?
>

Ok, so, gunna make me look, let's see, ok: 7.13.2.1p5, note the may's and
might's.  There should be narrative backing those up.


> On Jan 16, 2012, at 10:51 AM, Comeau At9Fans <comeauat9fans@gmail.com>
>> wrote:
>>
>> On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>>
>>> A frame pointer is needed for C99's variable length arrays but not
>>> otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x.
>>> gcc has to do the right thing even with -fno-frame-pointer.
>>>
>>
>> What we do in problematic cases with Comeau is to generate code to
>> arrange for the allocation of the VLA on the heap.  I'm not saying this is
>> perfect, but at least it gets the feature implementable and up and running
>> as "a portable implementation" versus perhaps not being able to implement
>> it at all on some platforms.
>>
>>
> Seems to me if you can port C, you can use a FP to implement VLAs without
> alloca games and more efficiently. You can always store the FP in stack
> local memory if out of registers.
>

I probably overstated the situation by saying not being able to implement
it at all... probably should have said I never thought of it beyond the
obvious implementations.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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