My generic port is shaping up. I keep wanting to call it the portable interpreter except that’s what people used to call the C++ interpreter so I keep ending up calling it the really portable interpreter or some such thing. All the “CPU-specific” files live in hotspot/src/cpu/zero and hotspot/src/os_cpu/linux_zero so I guess it’s called zero (it was snappier than “nothing”). It’s come to mean zero-assembler in my head although there is some assembler in there, a spinpause and a 64-bit atomic copy, but if I can’t write those for a new platform within a day or two then I probably need sacking!

Anyway, whatever it’s called, it’s shaping up. I have a funky stack class with a slightly odd allocation strategy to allow it to live in alloca allocated memory, I’ve written my call stub using it and am now working on the normal entry. I plan to use the same calling convention throughout, the stack-based one that the bytecode interpreter uses. I have no specific native calling convention I need to match, and doing it that way saves writing a load of result convertors.

Ok, back to coding…

2 thoughts on “

  1. I’m using GCC’s atomic builtins for that. The thing that I need is basically an array copy that copies 64-bits at a time. I don’t remember the details, but there’s a couple of really wacky bits in Hotspot where Java objects are moved without locking and it only works because the fields can’t ever be half-copied.

    I cheated on 32-bit PPC: the only way I could find to do 64-bits at a time was such a hack I decided just doing 32-bits would be better! And it seems to work (ie no-one complained yet…)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.