[M3devel] cg.alloca

[Jay K]

 - Are you ok with the ugly/inefficient strcmp?
 
 - And what will be a more significant but still not huge transform in m3back?
  alloca will translate to chkstk -- an actual function call, but renamed
 
  The parameter that was already pushed on the stack will be be poped into eax,
 whereas with an m3cg operation, it would have been put into eax more directly.
 
  The return sequence will probably mov esp into..either eax specifically, or any register..I don't think leaving it in esp is easy enough for m3back to deal with. Again a special case in the general function call/return path.
 
 
(In reality, the transform is quite significant in m3cc, but it is below where we work.)
 
 
It's a funny thing in general, these "built in functions" that get very special handling and aren't necessarily "functions" (as in "call"/"ret"). Not clear in general to me how to model them.
 
 
It makes one wonder why add/sub/multiply/div aren't builtin functions?
i.e. "everything" could be viewed as a function.
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 12 Jan 2011 13:34:16 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] cg.alloca
>
> No, the atomics can't be because they don't map directly to a gcc builtin, whereas alloca *does*.
>
> On Jan 12, 2011, at 1:06 PM, Jay K wrote:
>
> >
> > On NT386 the function is _chkstk, number of bytes in eax, return value in esp.
> > Notice how in parse.c I had to strcmp for the function name. A little gross, but it does work.
> > And C/C++ work that way.
> > Notice how you implemented atomics.
> >
> > I half agree though. It could be a function call even for NT386.
> > The atomics could be too.
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 12 Jan 2011 12:10:02 -0500
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] cg.alloca
> >>
> >> I don't see the reason for this. If alloca is imported and invoked the gcc backend will happily replace it with inline code.
> >>
> >>
> >> Antony Hosking | Associate Professor | Computer Science | Purdue University
> >> 305 N. University Street | West Lafayette | IN 47907 | USA
> >> Office +1 765 494 6001 | Mobile +1 765 427 5484
> >>
> >>
> >>
> >>
> >> On Jan 12, 2011, at 2:24 AM, Jay K wrote:
> >>
> >>>
> >>> proposed diff attached
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: jay.krell at cornell.edu
> >>>> To: m3devel at elegosoft.com
> >>>> Date: Wed, 12 Jan 2011 06:28:26 +0000
> >>>> Subject: [M3devel] cg.alloca
> >>>>
> >>>>
> >>>> I'd like to make alloca a separate operation in m3cg.
> >>>> Instead of a special function name that we check for.
> >>>> More like the atomics.
> >>>> I know how and can do it myself easily enough.
> >>>> ok?
> >>>>
> >>>>
> >>>> (and then I'll fix NT386)
> >>>>
> >>>>
> >>>> - Jay
> >>>>
> >>>>
> >>>
> >>
> >
>