[foreign] RFR: refresh layout grammar
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Thu May 24 01:33:52 UTC 2018
Quick comment:
test/jdk/java/nicl/System/UnixSystem.java
+ @NativeType(layout="[i32u16u16u64u32u32i64[i64i64][i64i64][i64i64][i64i64]i64i64i32u32u32i32[2i64]]", ctype="dummy")
@NativeLocation(file="dummy", line=47, column=11, USR="C:@S at MyStruct")
- @NativeStruct("[iSSQIIi[ll][ll][ll][ll]qqiIIi2q]")
You need to put new layout string in @NativeStruct as struct interfaces
no longer use @NativeType.
PS. I'll test the patch on Mac.
-Sundar
On 24/05/18, 1:29 AM, Maurizio Cimadamore wrote:
>
>
> On 23/05/18 20:26, Henry Jen wrote:
>> On May 23, 2018, at 11:40 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>>
>>>
>>> On 23/05/18 19:10, Henry Jen wrote:
>>>>> On May 23, 2018, at 9:46 AM, Maurizio Cimadamore
>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>> I've put together a change which tweaks the grammar of layout
>>>>> descriptions used in annotations to correspond to what's described
>>>>> here [1].
>>>>>
>>>>> The big changes are in DescriptorParser, which now has to
>>>>> understand the new grammar, and also in TestDescriptorGrammar,
>>>>> which has to combinatorially generate sentences of the new grammar.
>>>>>
>>>>> All the other tedious changes are test changes, required to go
>>>>> from the old to the new grammar; I've adhered to the following rules:
>>>>>
>>>>> 'b' -> ‘u8'
>>>> b is a bit, so should it be u1?
>>> uhm - booleans don't exist in C, so typically a byte will be
>>> allocated holding a 1 or a 0. You can think of it as
>>> u8[u1(value)u7(padding)] if you want, but the results are the same?
>> b is for bit-field, so that definitely a u1.
> My bad then
>
> I meant B -> 'u8' :-)
>
> Maurizio
>> B is for boolean, that is _Bool in C, the x64 ABI state is 1 byte in
>> size and alignment, so u8 is fine.
>>
>> Cheers,
>> Henry
>>
>>>> o is octet, which is the byte and should be u8.
>>> ok, I haven't seen octets around in existing tests
>>>>> 'c' -> ‘i8'
>>>> char is either signed or unsigned depends on platform. Since we are
>>>> targeting x64 for now, unsigned is correct.
>>> ok
>>>
>>> Maurizio
>>>>> 's' -> 'i16'
>>>>> 'i' -> 'i32'
>>>>> 'l' -> 'i64'
>>>>> 'q' -> 'i64'
>>>>>
>>>>> Also note that in the new grammar capital letter denote
>>>>> big-endiannes, while in the old one they meant unsigned-ness.
>>>>>
>>>>> There's a trivia in the DoubleUpcall test, which was using
>>>>> 'unsigned double' ('D') - not sure why…
>>>> Hmm, not sure.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>>> Webrev here:
>>>>>
>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/layout-grammar-refresh/
>>>>>
>>>>>
>>>>> P.S.
>>>>> Might be useful to give it a spin on Mac and see if UnixSystemTest
>>>>> works (the layout conversion was not very trivial w/o jextract
>>>>> support :-))
>>>>>
>>>>> Cheers
>>>>>
>>>>> Maurizio
>
More information about the panama-dev
mailing list