[foreign-abi] On invokers

[Maurizio Cimadamore]

I've further slightly simplified the code, by getting rid of 'spillStruct'.

http://cr.openjdk.java.net/~mcimadamore/panama/programmableInvoker-sysv_v2/

I realized that when we don't have enough register I just have to return 
enough stack VMStorage to cover all the classes obtained during 
classification.

I've also simplified allocation of stack storage - after all, in SysV, 
the expectation is that stack is used to store eight-bytes, so we just 
need a simple counter which keeps track of how many stack eight-bytes we 
have handed out.

All tests seem happy with this.

Maurizio

On 28/10/2019 17:21, Maurizio Cimadamore wrote:
> Updated webrev
>
> http://cr.openjdk.java.net/~mcimadamore/panama/programmableInvoker-sysv_v2/ 
>
>
> Maurizio
>
> On 28/10/2019 16:57, Maurizio Cimadamore wrote:
>>
>> On 28/10/2019 14:41, Jorn Vernee wrote:
>>> Hi Maurizio,
>>>
>>> Thanks for doing the SysV implementation!
>>>
>>> Some comments on CallArranger:
>>> - You are still using the WinABI layout constants in places; e.g. 
>>> `MemoryLayouts.WinABI.C_POINTER` when generating in memory return 
>>> bindings.
>> Whoops - I will fix this.
>>> - For upcalls with in memory returns there is a return binding for 
>>> the buffer address, but this is only needed on Windows, so it can be 
>>> removed for SysV.
>> I'll take a look.
>>>
>>> I didn't review the layout classification, as I'm not familiar with 
>>> that code (I assume it's still the same any ways?)
>>
>> The classification is the same logic as we have currently - as I 
>> thought it would have been safer to start from there - and maybe 
>> cleanup the code later. So, what I did was to bridge the old 
>> classification code and make it work with the new API. I originally 
>> thought the classification logic could be made simpler - e.g. just 
>> return a TypeClass; but I later realized that the SysV is inherently 
>> more complex with structs than Win64 and Aarch64 - where we 
>> essentially can have only one register kind per struct; in SysV a 
>> struct can use multiple register kinds, which means we need to keep 
>> track of a more fine-grained classification. Probably there is some 
>> simplifying move lurking in there, but I thought it would be better 
>> to get the test passing and to push back the work, and then work on 
>> code quality issues.
>>
>> Cheers
>> Maurizio
>>
>>>
>>> Thanks,
>>> Jorn
>>>
>>> On 26/10/2019 01:55, Maurizio Cimadamore wrote:
>>>> Sorry for the delay.
>>>>
>>>> Here's a port of SysV of the programmable invoker. The code can be 
>>>> improved, but passes all tests (I fixed one test in 
>>>> TestUpcall/Downcall which was actually causing certain checks to be 
>>>> skipped, resulting in spurious passes, so I recommend that other 
>>>> patches are re-tested also). I also tried the support with a 
>>>> libclang port I have on top of the foreign-abi support, and 
>>>> everything worked reliably.
>>>>
>>>> Patch here:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/panama/programmableInvoker-sysv/ 
>>>>
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>> On 24/09/2019 10:42, Jorn Vernee wrote:
>>>>> If you want to do a SysV port that would be much appreciated :). 
>>>>> In principle everything in the `programmable` package, except for 
>>>>> CallArranger is a part of the API, though there should be no need 
>>>>> to interact directly with BindingInterpreter and BufferLayout. So, 
>>>>> if you want to do a port the only thing you should have to do is 
>>>>> add a SysV version of CallArranger, (which I based on 
>>>>> CallingSequenceBuilderImpl, so that's probably a good place to 
>>>>> start) and then call that from SysVx64ABI.