[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