[Vm-dev] [Squeak 0007821]: Make generated interpreter code compatible with Plan9's POSIX C compiler

[Alex Franchuk]

On 10/02/2014 10:44 AM, Bert Freudenberg wrote:
>   
>
>
> On 02.10.2014, at 16:05, Alex Franchuk <alex.franchuk at gmail.com> wrote:
>
>> The changes were:
>> 1. Fix a couple incorrect/faulty C type declarations for certain methods and scoped variables within the methods.
>> 2. Ensure functions which declare a return type will return some value at the end of the block (defaulting to null).
>> 3. Ensure assignments are properly casted when type data about the expression and variable is available.
>> 4. Ensure functions arguments are properly casted when type data about the function's parameters and the argument expressions is available.
> That sounds rather useful. I need better type information, too.
>
> E.g., I'd like to know that firstIndexableField() is really an 'unsigned char *' here, not a 'void *' as declared:
>
> unsafeByteOf: bytesOop at: ix
> 	"Argument bytesOop must not be aSmallInteger!"
> 	<inline: true>
> 	| pointer |
> 	<var: #pointer type: #'unsigned char *'>
> 	^(pointer := interpreterProxy firstIndexableField: bytesOop) at: ix - 1
>
> I thought I could use the scopeStack but that appears to not be available when generating code ...
>
> - Bert -
>
Right now the type data is only obtained by using the typeOfVariable 
method of the CCodeGeneration instance, or the arguments property of the 
TMethod instance, and unfortunately these return both the type and the 
name of variable, as if it were a declaration, so my code tries to get 
the type from this (it may not always work).

Ideally typeOfVariable would return only the type, and perhaps a new 
method like declarationOfVariable would return what typeOfVariable 
currently returns. That would be more reliable, and scoped variables 
could perhaps be tracked through the CCodeGeneration instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141002/191ca1f9/attachment-0001.htm