[Vm-dev] ARM Cog progress

Eliot Miranda eliot.miranda at gmail.com
Tue Jun 9 15:36:07 UTC 2015

On Mon, Jun 8, 2015 at 7:54 PM, Ryan Macnak <rmacnak at gmail.com> wrote:

> On Sun, Jun 7, 2015 at 8:58 AM, tim Rowledge <tim at rowledge.org> wrote:
>> On 07-06-2015, at 12:32 AM, Holger Freyther <holger at freyther.de> wrote:
>> >> On 07 Jun 2015, at 01:25, tim Rowledge <tim at rowledge.org> wrote:
>> >>
>> >>
>> >> GCC is such fun.
>> >
>> > given the amount of warnings emitted during compilation, have you
>> considered
>> > that it might be the input given to gcc that is the issue here? ;)
>> I dunno; I get a total of 59 warnings when compiling the ARM Cog VM, none
>> in the core vm code. I’d love to see it be 0. I rather suspect the world
>> would come to an end if that happened.
>> On the other hand, I can’t see how it is acceptable for a compiler to
>> produce code that blows up at one level of optimisation but not at another.
>> Come to that I’m not sure why there are different levels; I can sort of see
>> asking to optimise in different ways  - the NorCroft compiler for ARM can
>> be asked to optimise for runtime speed or executable size, for example.
> I'm inclined to believe Cog is relying on undefined behavior somewhere,
> and this isn't gcc's fault. I've not built functional Newspeak VMs on
> modern compilers since ~1317, but this overlaps with the VM being broken on
> old compilers for other reasons so I haven't figured out what change is
> responsible.

Hi Ryan,

    IMO the likely issue is register usage in trampoline calls.  The JIT
tries to reduce register saving and restoring across trampoline calls by
using a notion of the ABI's caller-saved registers.  Callee-saved registers
shouldn't be an issue because either a run-time call returns to the same
trampoline that invoked it, hence restoring callee-saved registers, or
enters machine code via an enlopmart which assumes no registers are live
and restores any and all registers as appropriate.  But there could be bugs
here, and certainly gcc could change over versions, perhaps becoming more
aggressive in register saving, and surfacing previously undetected bugs

One thing to do is compare a StackInterpreter VM against Cog, at least to
locate the blame.  Then, if the finger does point at the Cogit, to locate
the issue after setting up a reproducible case, run with some kind of
tracing (e.g. each message selector, but the Cogit could straight-forwardly
add tracing to the trampolines) to see what the VM is doing immediately
before the crash.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150609/18425465/attachment-0001.htm

More information about the Vm-dev mailing list