From: steve@digibd.com (Steve Wahl)
Subject: Re: Lack of libPW.a module
Organization: DigiBoard Incorporated, Eden Prairie, MN
Date: Tue, 08 Sep 1992 20:58:23 GMT

=======================================================================
The short story for those who don't want to read the whole thing: I
was wrong, on the 3B1 you don't have to worry about register variables
conflicting with alloca() (I made a mistake generalizing what I knew
about a different archetecture).  You still have to worry about
complex uses of alloca() - for the record I never disagreed with that.
=======================================================================

In article <89582@rphroy.ph.gmr.com> tkacik@hobbes.hobbes.cs.gmr.com writes:
>In article 4632@digibd.com, steve@digibd.com (Steve Wahl writes:
>> I don't think anyone understands me yet.  First, some context.
>> 
>> In article <1992Aug29.052011.24352@colnet.cmhnet.org> res@colnet.cmhnet.org (Rob Stampfli) writes:
>> >In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
>> >
>> >>   [ don't use alloca() with register variables ]
>
>All passed parameters and local variables will be ahead of the alloca'd
>space, and will be accessed via the frame pointer (%a6) rather than the
>stack pointer (%sp aka %a7).  Only temporary variables are accessed via
>the stack pointer.

This is the part I didn't remember correctly; I've been working on a
different, little-endian archetecture ( guess :-) ) lately that DOES save
and restore the register variables via the stack pointer rather than the frame
pointer (well, the compilers we use do this, anyway...), and I thought
I remembered the 68010 compiler doing the same thing.  Andy Fyfe also
pointed out this error to me.

>
>All of the saved parameters, passed parameters, and local variables
>are accessed via the frame pointer, not the stack pointer.  Your line
>marked "**************" should use %a6.  (Actually, what will happen
>is the link instruction is given a mask telling it which registers to
>save.  Neither your save %d2, nor restore %d2 will be generated by
>the compiler.  The Unlink instruction will restore the proper
>registers from the stack, again using %a6 not %sp.)

Now, after I stuck my foot in my mouth last time, I don't want to
sound so sure of myself this time.  But I don't remember link and
unlink being able to save or restore registers.  Link takes two
parameters, the frame pointer and an offset to add to the stack
pointer for allocating local stack space.  The unlink instruction
takes one parameter, the frame pointer.  I believe if you really
examine the code ouput by the compiler, you will find two movem
instructions, one after the link and one before the unlink, that take
care of saving and restoring registers.  As a matter of fact, this is
the compiler output Andy showed me:

        set     S%2,-4
        set     T%2,-8
        set     F%2,-12
        set     M%2,0x0004
        text
f2:
        link    %fp,&-12
        movm.l  &0x0004,S%2(%fp)
        mov.l   &7,%d2
        mov.l   &10,%d0
        mov.l   %d0,(%sp)
        jsr     alloca
        mov.l   %d0,%a0
        mov.l   %a0,-4+S%2(%fp)
        mov.l   %d2,%d0
        movm.l  S%2(%fp),&0x0004
        unlk    %fp
        rts
 
This, of course, is a completely separate issue, and the compiler
still works as advertised...

--> Steve


-- 
Steve Wahl               steve@digibd.com
Digi International, Inc.
Eden Prairie, MN         (612) 943-5387