[M3devel] cg.alloca

[Tony Hosking]

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