FInfo->codesize woes.
Hi YHC! Greetings, and for those I haven't already pestered, my interest in YHC pertains to my third year project, creating a JIT compiler for YHC's bytecode. Does anyone know if the FInfo->codesize value is reliable? I am presently compiling the _driver function which states a codesize of 0x24, yet my JIT compiler shows the IP (when I reach an END_CODE op) falls about 6 bytes short of this. Also is every function guaranteed to have an END_CODE op at the end? My current code works for a selection of functions I have played with but I haven't had time to examine any more than a modest selection. Cheers, Stew.
Hi Stew,
Hi YHC! Greetings, and for those I haven't already pestered, my interest in YHC pertains to my third year project, creating a JIT compiler for YHC's bytecode.
Ah excellent :-)
Does anyone know if the FInfo->codesize value is reliable? I am presently compiling the _driver function which states a codesize of 0x24, yet my JIT compiler shows the IP (when I reach an END_CODE op) falls about 6 bytes short of this.
The codesize is indeed reliable, though interestingly enough I get the codesize for _driver being 25 bytes rather than (0x24 = 36 bytes). I've just checked and 25 bytes is indeed correct (including 1 byte for the END_CODE itself). Here is a printout of the function, as loaded by the interpreter. FInfo _driver [ arity: 2, consts: 7 ]{ 0. [0x1b] ZAP_ARG 0 2. [0x01] NEED_HEAP_32 3. [0x25] PUSH_CONST_0 4. [0x30] MK_AP_1 5. [0x27] PUSH_CONST_2 6. [0x18] PUSH_ZAP_ARG_1 7. [0x28] PUSH_CONST_3 8. [0x41] APPLY 2 10. [0x01] NEED_HEAP_32 11. [0x33] MK_AP_4 12. [0x34] MK_AP_5 13. [0x0b] PUSH_ZAP_0 14. [0x5a] EVAL 15. [0x5c] TABLE_SWITCH [1] {0 -> 20} 20. [0x01] NEED_HEAP_32 21. [0x4a] UNPACK 22. [0x2b] PUSH_CONST_6 23. [0x5b] RETURN_EVAL 24. [0x00] END_CODE consts { 0. NODE 0xb6ca222c [(CExitSuccess)] 1. INFO FInfo 'reallyExit'[1] 2. NODE 0xb6ca223c [(FLAMBDA294/1)] 3. NODE 0xb6ca2748 [(Fcatch/0)] 4. INFO FInfo 'YHC.Internal.IO;Prelude.Monad;>>'[2] 5. INFO FInfo 'unsafePerformIO'[1] 6. NODE 0xb6ca2754 [(Fundefined/0)] } }
Also is every function guaranteed to have an END_CODE op at the end? My current code works for a selection of functions I have played with but I haven't had time to examine any more than a modest selection.
Yes the compiler always places END_CODE at the end of every function. END_CODE crashes the interpreter if it's ever executed, it's designed to catch any problems with miscalculated jumps. Hope that helps :-) Tom
Thanks for the reply Tom (and in reply to your message, I am modifying the interpreter)!
The codesize is indeed reliable, though interestingly enough I get the codesize for _driver being 25 bytes rather than (0x24 = 36 bytes). I've just checked and 25 bytes is indeed correct (including 1 byte for the END_CODE itself). Here is a printout of the function, as loaded by the interpreter.
Aha, seems I threw something of a red herring with the 0x24, it was in
fact decimal 24. Judging from my current output (Warning, assembly): http://modseven.de/pastebin.php?id=1802 something went wrong around the NEED_HEAP_32 / UNPACK area. I'll investigate it and see how it goes, cheers, Stew.
Stewart Platt wrote:
Thanks for the reply Tom (and in reply to your message, I am modifying the interpreter)!
Yes, I think that's probably going to be the easiest way forward, all the loading code etc is quite fiddly and there's no need to duplicate it :-)
Aha, seems I threw something of a red herring with the 0x24, it was in fact decimal 24.
Ah, I'd wondered if that might be the case :-)
Judging from my current output (Warning, assembly): http://modseven.de/pastebin.php?id=1802 something went wrong around the NEED_HEAP_32 / UNPACK area.
Indeed, you seem to have lost a few instructions, some of the earlier ones seem to be out of order as well, though that could be deliberate :-) Looking at the assembly is interesting, looking good so far. There are some definite possibilities for optimization such as keeping the stack pointer in a register, and not using CALL to do MK_AP, NEED_HEAP, EVAL etc. Though you may well have these things in mind already :-) One thing to be careful of is RETURN_EVAL, this is because it should implement tail call optimisation, which can be fiddly. Of course your example doesn't include any assembly for it, so it might be correct already :-) Anyway, good luck, I'll be interested to hear how it goes :-) Tom
participants (2)
-
Stewart Platt -
Tom Shackell