[Vm-dev] arm64 struct passing orientation

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 25 21:46:34 UTC 2019


Hi Ken,

On Thu, Jan 24, 2019 at 4:37 PM <ken.dickey at whidbey.com> wrote:

> OK.  I could use some help here.
>
> I think I see what is going on with failing unit test FFIPluginTests>>testPoint4
>
> I am not sure yet how to deal with it.
>
> Looking at the code in gdb, ffiTestStructBig() expects the 4 int values of pt1 in regiters x0,x1 and pt2 in x2,x3 and result p3 returned as x0,x1.
>
>
That's right.  Read (very carefully) section 5.4.2 Parameter Passing Rules
of Procedure Call Standard for the ARM 64-bit Architecture.  It states in
Stage B that a composite type is only padded and passed in memory if:

B.1 If the argument type is a Composite Type whose size cannot be
statically determined by both the caller and the callee, the argument is
copied to memory and the argument is replaced by a pointer to the copy.
(There are no such types in C/C++ but they exist in other languages or in
language extensions).

B.3 If the argument type is a Composite Type that is larger than 16 bytes,
then the argument is copied to memory allocated by the caller and the
argument is replaced by a pointer to the copy.

and it states in Stage C that:

C.10 If the argument is a Composite Type and the size in double-words of
the argument is not more than 8 minus NGRN, then the argument is copied
into consecutive general-purpose registers, starting at x[NGRN]. The
argument is passed as though it had been loaded into the registers from a
double-word- aligned address with an appropriate sequence of LDR
instructions loading consecutive registers from memory (the contents of any
unused parts of the registers are unspecified by this standard). The NGRN
is incremented by the number of registers used. The argument has now been
allocated.

So the code in ThreadedARM64FFIPlugin>>ffiCallOutTo:SpecOnSTack:in: and
ffiReturnStruct:ofType:in: must obey these (rather tricky and inconvenient)
marshaling rules.  That's life :-)

The call, however, seems to be putting a pointer to an allocated pt3
in x0, pt1 values in x1,x2 and pt2 values in x3,x4.
>
> So I am looking at ThreadedARM64FFIPlugin>>ffiCallOutTo:SpecOnSTack:in: and ffiReturnStruct:ofType:in: but have not yet worked through the logic of the niggly bits.
>
> So I be deep into the steenking pile, mon!
>
>
Well, it might seem like that. Optimization all cost always makes things
more difficult, but there are claimed benefits ;-)

> Any insights thrown over the wall would be appreciated.
>
>
The x86 has somewhat less ambitious rules (except early drafts that gave me
headaches in the VisualWorks VM), but also passes small structs in
registers.
See ThreadedX64SysVFFIPlugin>>#ffiPushStructure:ofSize:typeSpec:ofLength:in:.
That method passes small structures in registers and points to the relevant
section of the SysV calling convention that specifies the behavior.

As encouragement let me say that this is the most difficult part of the
process, so once you have this solved you will have passed the summit.
Since it's the last thing you;'re working on anyway that might not be
comfort un less you get a high out of conquering a challenge (which I hope
and suspect you do).

If you get stuck I can try and find some time to set up may 64-bit ARM and
jump into the pre-methane pool with you ;-)


Thanks much,
> -KenD
>
>
One  might think that a dry suit is appropriate garb, but sitting in them
for long periods of time gets sweaty.  Just use a clothes peg over the nose.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190125/0305b3c1/attachment.html>


More information about the Vm-dev mailing list