[Vm-dev] Microhackathon [WAS Help: Float returns on RISCV]

Boris Shingarov boris at shingarov.com
Mon Jul 11 23:07:12 UTC 2022


I was leafing through the TA-Cog code in preparation for the approaching 
microhackathon, and I just thought about something fun.

I think EVEN IN THE ABSENCE OF SAIL there is still interesting static 
analysis one can perform on Cog by abstract interpretation.  Namely, the 
chain of sends from Cogit>>gen: through Cog*Compiler>>concretize 
ultimately ending up at cond:type:op:set:rn:rd:shifterOperand: and 
friends, when executed with an abstract state, will leave what I call an 
"n-zonelet" (rhymes with SL guys' "heaplet") which is a bunch of 
instructions whose operands are ASTs.  Because the Petrich2 Disassembler 
already knows how to handle symbolic instruction memory, at a minimum I 
can imagine automatic removal of cond:type:op:set:rn:rd:shifterOperand: 
-like methods / refactoring of concretize* into native assembly (the 
latter we already know how to assemble back into executable JIT).  Much 
more interesting is Diophantine question "for which values of 3 does 
this construction work?"  Even without looking at semantics this already 
can be an interesting question.  For example, you can't pass anywhich 
Integer wordConstant to MoveCw:R:, it has to fit in machine word.  Now, 
the Petrich2 assembler/disassembler pass around BitVectors, not 
Integers, so the question arises: at which point to convert Integer to 
BitVector?  In theory, the Horn solver in MachineArithmetic can 
synthesize intermediate or "local" Floyd-Hoare VCs, but the problem is 
that there is nothing at the "left-most precondition" end.  For example, 
MoveCw:R: does not include a "self assert:" which might reject 
out-of-range wordConstant, and there is nothing inherent (one choice 
wouldn't be inherently better than other: we may equally well choose to 
wrap-around, or to disallow going out-of-range).

Hmm.

Looks like this area will be fun to play in.

On 7/1/22 23:50, Jan Vrany wrote:
> On Fri, 2022-07-01 at 06:15 -0700,ken.dickey at whidbey.com  wrote:
>> While I hate to call "compiler codegen bug", at this point I suspect a
>> tool issue with gcc [Debian 10.2.1-6 2021-01-10].
>>
>> I would like to try with an updated gcc and I probably need to craft a
>> small example which either teaches me how to avoid the problem or can
>> convince the compiler port/maintainers that there is a problem.
> The code is "difficult to read" to put it mildly, but - after a cursory look
> at it - I believe the code generated by GCC is correct.
>
> The function being called in
>
>     floatRet.d = dispatchFunctionPointerwithwithwithwithwithwithwithwith...
>
> is declared to return a struct of size greater than 2*XLEN. so it is "returned"
> by reference passed to the callee as implicit first argument. Therefore, there
> is no need to "assign" to float.d after callee returns, it's already done
> (or, I should say, the compiler is free to assume that). This is exactly what
> I see in your asm output in one of your previous emails.
>
> See RISC-V ELF psABI [1].
>
> [1]:https://github.com/riscv-non-isa/riscv-elf-psabi-doc
>
> HTH, Jan
>
>> Single stepping in gdb (stepi) just shows that the floatRet.d is not
>> getting set to the result -- no code to do this.
>>
>> As as aside, the AllWinner D1 works fine but is vvvvveeeeeeeerrrrrryyy
>> ssllllloooooowww. So building and debugging takes patience.
>>
>> The great news is that both Cuis and Squeak images run fine (unless you
>> load compressed files, which yield CRC errors).
>>
>> I do have some time tomorrow (Saturday; 2 July) in Pacific Time Zone,
>> but I am not sure how we might proceed to trouble-shoot the problem.
>>
>> It would be good to talk with you in any case.
>>
>> Cheers,
>> -KenD
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220711/64b4c0e4/attachment.html>


More information about the Vm-dev mailing list