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

[John McIntosh]

>Right.  The stack should be properly aligned on a 128-bit/16-byte boundary
for SSE instructions to work correctly.

Note when we developed Sophie we found the quicktime engineers
took advantage of this 16 byte boundary alignment and for some FFI
quicktime calls would cleverly say oh look we need 4 bytes, and gee we know
we have X input parms, but because the stack is aligned why there is four
bytes FREE up there to use as working space so we avoid some sort of
allocation or stack adjustment! This of course trashes something on the
stack, usually an OOPS value, and crash happens a bit later...


On Tue, Oct 20, 2015 at 2:26 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Esteban,
>
> 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.
>>
>
> Right, but oops are squints which are signed, so this shouldn't be a
> problem.  We can't safely cast the value to signed because, unless we know
> the size of the integer, we may truncate it.  e.g. (signed)integerValue is
> equivalent to (int)integerValue, and if integerValue were 64-bits the cast
> could cause the wrong answer.
>
>
>> 2) assertCStackWellAligned always fail. No idea why because if does not
>> says anything, just jmp back to the regular flow.
>>
>
> Put a breakpoint in warning and then you can see what the problem is.
>
>
>>
>> 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).
>>
>
> Right.  The stack should be properly aligned on a 128-bit/16-byte boundary
> for SSE instructions to work correctly.  So you need to step through the
> code generated for  ceCaptureCStackPointers,and look at the execution
> state when assertCStackWellAlignedis evaluated.  For this you must use a
> debugger and puzzle out the code at the machine level.
>
> I guess solution of (1) is easy: argument number just has to be a sqLong
>> instead an unsigned long.
>>
>
> Right.  Extremely important :-)
>
>
>>
>> But for 2 and 3 I have no idea where to start.
>>
>> Does anyone has an idea?
>>
>
> Roll your sleeves up and dive in with gdb/lldb.  And you can contact me
> via Skype or FaceTime if you want to talk it through and let me look over
> your shoulder.
>
>
>> Esteban
>>
>
> _,,,^..^,,,_
> best, Eliot
>
>


-- 
===========================================================================
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/2907a3a3/attachment.htm