[Vm-dev] Plugin code generation issues
Eliot Miranda
eliot.miranda at gmail.com
Mon Mar 9 16:46:56 UTC 2020
Hi Levente,
> On Mar 9, 2020, at 8:54 AM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>
> Hi All,
>
> I wrote a new plugin the other day and found two issues with code generation.
> The first one, which is less important is related to the inline pragma.
> I expected that methods marked with <inline: true> will either not be generated at all when the code generator inlines all occurrences of them or they'll be generated as inline C functions. But they are generated as regular static functions even though they are never used.
Slang is not always able to inline. For a example, inlining into conditionals is problematic. For this reason Slang treats <inline: true> as a recommendation. If you want to insist, eliminate the static functions, and deal with any failures to inline by suitable rewrites then use <inline: #always>.
Slang also obeys <inline: #never> which is useful in other ways (for example reducing code duplication).
> The other one, which is more significant is related to type casts.
> I've got the following method:
>
> rotateRight64: value by: amount
>
> <inline: true>
> <var: #value type: #'unsigned long long'>
> <returnTypeC: #'unsigned long long'>
>
> ^(value >> amount) bitOr: (value << (64 - amount))
>
> The code using the above method has the variable declaration
>
> <var: #w declareC: 'unsigned long long w[80]'>
>
> The method is used with individual elements of w:
>
> self rotateRight64: (w at: i - 2) by: 61
>
> The generated function gets inlined as expected, but the elements of the array are casted to usqInt before right shifts:
>
> ((((usqInt) (w[i2 - 2])) >> 61) | ((w[i2 - 2]) << (3)))
>
> This is a problem on 32-bit platforms, because usqInt is unsigned int there, so the upper 32-bits will be lost by the cast.
>
> When the method is used with non-array variables, then the generator works as expected:
>
> self rotateRight64: a by: 39
>
> is generated as:
>
> ((a >> 39) | (a << (25)))
>
> where a is declared as
>
> <var: #a type: #'unsigned long long'>
>
> I tried to fix the issue by declaring w as
>
> <var: #w type: #'unsigned long long*'>
>
> But is didn't make the usqInt casts go away.
> Is it possible that the code generator doesn't know that the type of w[i] is unsigned long long, when w is unsigned long long*?
I’ll need to take a look at this in detail. For now, try using the type #usqLong and see if it makes a difference.
> Levente
>
> P.S.: The code is available here http://squeaksource.com/Cryptography/CryptographyPlugins-ul.18.mcz .
> Generate SHA2Plugin to see the problem.
More information about the Vm-dev
mailing list