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 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