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

[Alex Franchuk]

On 10/02/2014 07:43 PM, David T. Lewis wrote:
>   
> On Thu, Oct 02, 2014 at 12:36:06PM -0400, Alex Franchuk wrote:
>>   
>> 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.
> One related suggestion: In TSendNode>>emitCCodeAsFunctionCallOn:level:generator:
> the declToType block might better be implemented as a separate method to
> make it easier to see what the code generator is trying to do. It might
> look like this:
>
> TSendNode>>variableDeclarationToCType: declarationString
> 	"Answer a C type string corresponding to the C variable declared in declarationString"
> 	| strs ind |
> 	declarationString isNil ifFalse: [
> 	strs := declarationString subStrings: ' '.
> 	ind := 0.
> 	strs size > 1
> 		ifTrue:
> 			["Bit of a hack to get 'type *'"
> 			[(strs second at: (ind+1)) isSpecial] whileTrue: [ ind := ind + 1 ].
> 			^ strs first, (strs second copyFrom: 1 to: ind)]
> 		ifFalse:
> 			[ ^strs first ]]
>
I definitely agree with that. The reason I didn't make it a separate 
method was because I was thinking that such a hacky way of getting the 
type should be replaced altogether with the type being stored separately 
from the declaration string, and that I might do that in the future if 
there was demand from others for it (which it sounds like there is). 
Otherwise as it is now it does at least produce code that Plan9 can compile.