The initial scheme code:
(define seg (assemble (compile 321)))
(define env (environment-copy (interaction-environment)))
(define cseg (sassy-postpass-segment seg))
(define linked (link-lop-segment cseg env))
Note that the "program" we're compiling here is just evaluating the literal
321. Not very exciting to interpret, but to run off the heap, marvelous!The (insane) hack on the x86 implementation of MacScheme's invoke:
dec dword [GLOBALS+G_TIMER]
jnz short %%L1
%%L0: mcall M_INVOKE_EX
jmp short %%L1
%%L2: storer 0, RESULT
const2regf RESULT, fixnum(%1)
int3 ;; debugging interrupt
;;; (the lack of space is significant; gdb ignores "int 3")
add TEMP,-BVEC_TAG+BVEC_HEADER_BYTES
jmp TEMP
%%L1: lea TEMP, [RESULT+(8-PROC_TAG)]
test TEMP_LOW, tag_mask
jnz short %%L0
;; Felix inserted checks if we actually have a
;; fixnum here...
mov TEMP, [TEMP-8+PROC_CODEVECTOR_NATIVE]
test TEMP_LOW, fixtag_mask
jnz short %%L2
storer 0, RESULT
const2regf RESULT, fixnum(%1)
jmp TEMP
The heart of the hack is that invoke is now dispatching based on the kind of code pointer it got. This should allow me to keep using Petit for the heart of the system, but still test the code in the heap directly.
- For fixnums (which are actually addresses into the text segment, but don't tell the garbage collector), we do the old invocation routine.
- For bytevector pointers (which should point at codevectors in the heap), strip the tag off the pointer, then add the offset to skip over the bytevector header (on the heap object itself). Finally, JUMP!
And, at long last, the actual result:
(gdb) r -heap sassy.heap
Starting program: /home/pnkfelix/larcenydev/trunk/larceny_src/twobit.bin -heap sassy.heap
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...LARCENY_ROOT not set; using current directory
Larceny v0.91 "Children's Ice Cream" (May 2 2006 10:41:54, precise:Linux:unified)
> (load "testsass.scm")
> (linked)
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08342d49 in ..@6866.L2 ()
(gdb) stepi
0x08342d4c in ..@6866.L2 ()
(gdb) stepi
0x00767454 in ?? ()
(gdb) c
Continuing.
321
Did you see it??? Did you??? That 321 at the end, that was produced by code in the heap. (Well, the value was; the actual action of printing the value is still happening from code in the text segment).
Woo hoo!!!
