J J writes:

Hello all,

I sent this to the Exupery list, but no one answered. Maybe someone here knows or has some pointers to where the information is

Hi, I've been on holiday, just got back home last night.

...

I was just curious how Exupery is able to directly generate the machine codes for a given platform. Squeak runs on a ton of platforms, so Exupery would have to have some way to know the codes for all of them.

Exupery will need to be ported to each CPU. This does add to the effort to do a port to a new architecture but Exupery isn't required to run Squeak, it just makes it faster.

...

I am curious because I was wondering about generation of the Squeak VM. Right now it is done with a smalltalk looking language called Slang (as you all know) that just converts directly to C. My thinking was the VM generator should at a minimum be a GCC front end and possibly build the executable itself (the problem with being a GCC front end is that it targets C, which may not be flexible enough). This might allow the VM to do some optimizations it can't at the moment (I seem to remember that C doesn't give you the information about float overflows, perhaps this might be useful to a language like smalltalk that doesn't make one pick the size of their numbers).

Do you mean integer overflows rather than float overflows? Exupery currently uses the CPU flags to do cheap overflow checks for SmallIntegers. Floats are slow in Squeak because they're full objects, and I don't think they are overflow checked.

There may be no performance gains from targeting GCC intermediate rather than C because the interpreter spends most of it's time recovering from branch mispredicts. There is spare cycles to do more real work while the pipeline refills afterwards. Moving to GCC intermediate would make portability harder, it is also a move from a well known and documented language (C) to an under documented language (GCC intermediate) which will reduce VM maintainability.

...

I haven't looked far enough to see if this would be worthwhile, and I also wonder how such a change would play with Exupery.

In a system with Exupery any gains to the interpreter will be less important because most of the time should be spent in compiled code not interpreted code. Interpreted performance will still matter for a few niche activities such as running Exupery's tests and starting an image.

Bryce