[M3devel] cg.alloca

[Tony Hosking]

On Jan 12, 2011, at 3:09 PM, Jay K wrote:

> 
> - Are you ok with the ugly/inefficient strcmp?

Where?

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

That's fine.  I don't want to complicate m3middle for m3back, which is designed for speed not performance of the resulting code.

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

Indeed.

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