[Vm-dev] Alien on Spur and "el capitan"?

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Oct 20 21:25:50 UTC 2015


The analysis I performed in 2013 was this one:

positive32BitIntegerFor: takes a positive 32 bit C integer, and make a
Smalltalk integer object out of it (possibly a LargePositiveInteger in 32
bits VM)

The intention is clearly to pass a uint32 parameter, so the parameter must
be unsigned and there is no point in testing if parameter is > 0.
AFAIR, all the send sites in VMMaker/plugins were in accordance with this,
but I changed many type int in senders
I made this change and I had a working VM passing all the tests.


For 64 bits VM, this should probably be an unsigned int (not a usqInt which
is too long).


2015-10-20 22:59 GMT+02:00 John McIntosh <johnmci at smalltalkconsulting.com>:

>
> Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH
> unsigned and signed integers? That to me rings alarm bells, so do you
> need maybeInlinePositive32BitIntegerForSignedInteger
> or maybeInlinePositive32BitIntegerForUnSignedInteger  or always cast the
> incoming value to an unsigned integer, or is it signed? If so are you sure
> you understand the math involved and the possible input values?
>
>
>
>
> On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>> Hi,
>>
>> Does anyone tested Alien on Spur and "El capitan"? specifically callbacks?
>> For me, a completely broken :(
>>
>> 1) this structure (in maybeInlinePositive32BitIntegerFor: and others):
>>
>> (integerValue >= 0
>> and: [objectMemory isIntegerValue: integerValue]) ifTrue:
>> [^objectMemory integerObjectOf: integerValue].
>>
>> Does not works if “integer value” is an unsigned long, because compiler
>> assumes it will always be true, then remove the if, then answers a wrong
>> value.
>>
>> 2) assertCStackWellAligned always fail. No idea why because if does not
>> says anything, just jmp back to the regular flow.
>>
>> 3) finally, ceCaptureCStackPointers also fails… this can be because (2)
>> or because other reasons (it also jmps back so no clue) (method
>> generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped
>> to work).
>>
>> I guess solution of (1) is easy: argument number just has to be a sqLong
>> instead an unsigned long.
>>
>> But for 2 and 3 I have no idea where to start.
>>
>> Does anyone has an idea?
>>
>> Esteban
>>
>>
>>
>
>
> --
> ===========================================================================
> John M. McIntosh. Corporate Smalltalk Consulting Ltd
> https://www.linkedin.com/in/smalltalk
> ===========================================================================
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151020/093f6b3e/attachment.htm


More information about the Vm-dev mailing list