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.
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
On Fri, 2022-07-01 at 06:15 -0700, ken.dickey@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
Ken, Jan:
I am reading through the code we showed at the Second Hackathon and now I remember what the holdup was with RV64 (and with 64-bit TaCog in general): SpurMemoryManager>>memoryClass. In simulated OpenSmalltalk, the Alien's mapped (non-fake) address space is backed by a Bitmap (in 32-bit) or a DoubleWordArray (in 64-bit). Under the ULD, there is no difference between production and simulation, so the address space is always the CPU's address space. But the rest of the simulator still thinks the memory is a Bitmap!!! So, I made a class called RemoteRAM, this is a proxy that looks like a Bitmap on the outside but is backed by the real RAM. This works perfectly well. However, I haven't gotten around to care a similar proxy for DoubleWordArray.
::browsing through the code of RemoteRAM::
Hmm... I *think* this what's on GitHub right now, *might* work. Back in 2020 when I wrote this, I was interested in demonstrating that Cog does fully boot on a never-supported-before processor (OpenPOWER) in a long-ago-abandoned endianness (BE); so I wasn't really careful about the other cases: they may have rotten. We will have to check, I think this would be our first step to get Cog on RV64.
Thursday I have an appointment, how about Friday? I am free all day.
Boris
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@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].
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
vm-dev@lists.squeakfoundation.org
-
Boris Shingarov -
Jan Vrany -
ken.dickey＠whidbey.com