<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I was leafing through the TA-Cog code in preparation for the
approaching microhackathon, and I just thought about something
fun.</p>
<p>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).<br>
</p>
<p>Hmm.</p>
<p>Looks like this area will be fun to play in.<br>
</p>
<div class="moz-cite-prefix">On 7/1/22 23:50, Jan Vrany wrote:<br>
</div>
<blockquote type="cite"
cite="mid:97ff7b83c134af8ec4b2abf4782649c3ea3f53e9.camel@vrany.io">
<pre class="moz-quote-pre" wrap="">On Fri, 2022-07-01 at 06:15 -0700, <a class="moz-txt-link-abbreviated" href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.com</a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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]: <a class="moz-txt-link-freetext" href="https://github.com/riscv-non-isa/riscv-elf-psabi-doc">https://github.com/riscv-non-isa/riscv-elf-psabi-doc</a>
HTH, Jan
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>