FW: Question about code generation

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.

Thanks,
Jason


_________________________________________________________________
Can’t afford to quit your job? – Earn your AS, BS, or MS degree online in 1
year.
http://www.classesusa.com/clickcount.cfm?id=866145&goto=http%3A%2F%2Fwww.classesusa.com%2Ffeaturedschools%2Fonlinedegreesmp%2Fform-dyn1.html%3Fsplovr%3D866143

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