( picoVerse-:( How do I get Exupery? ) )

[bryce at kampjes.demon.co.uk]

Kjell Godo writes:
 > On 10/16/08, bryce at kampjes.demon.co.uk <bryce at kampjes.demon.co.uk> wrote:
 > > Kjell Godo writes:
 > >  > I tried
 > >  > http://mfrouter.dyndns.org/Exupery_VM.7z
 > >  > but nothing happened.
 > >  >
 > >  > I am making an assembler in Dolphin Smalltalk.  It is trying to do all
 > >  > the addressing modes.  It is part of the picoLARC project on
 > >  > SourceForge.net but the assembler stuff is not uploaded yet.  It uses
 > >  > a Lispy syntax that looks like
 > >  > ( add ( into:From: EAX ( at ( + EBP 4 ) ) ) )
 > >  > or
 > >  > ( add ( into:From: EAX ( at ( scale:index:base: 4 EBX EBP ) ) ) )
 > >  > or
 > >  > ( push ( at EBP ) )
 > >  >
 > >  > Doing it this way seems to minimize the compiling complexity.
 > >  > Plus it can participate in the picoLARC OOP macro system.
 > >  > Your Exupery way is more like regular assembler.  It's brief and
 > >  > that's nice.  But you also do long function names for machine
 > >  > language instructions which is good.
 > >
 > > http://wiki.squeak.org/squeak/3945
 > >
 > > Exupery is a complete compiler, not just an assembler. It compiles
 > > Squeak's bytecodes dynamically in the image then executes them.
 > 
 > That sounds great.  Do you have CompiledMethods with native code in
 > them?  It sounds like you put the native code into a ByteArray or something
 > and then call the ByteArray.  If that is true could you point me at the
 > method where the code is put into the ByteArray and where it gets evaluated?

Look through AssemblerTests. It's the test class for Exupery's
assembler.

Exupery assembles into a ByteArray, then copies the byte array
into the code cache which is outside the image. Normal memory
isn't executable, and the GC can also move objects. Having a
separate code cache avoids both those problems.

 > >
 > >  > All the addressing modes are mostly finished coding but untested.
 > >  >
 > >  > I would like to use Exupery to test against my picoLARC assembler.
 > >  > If possible.
 > >
 > > It should be possible, that said if you're just testing an assembler,
 > > then just compare the bytes emitted. And there's often more than
 > > one way to assemble an instruction. Sometimes Exupery doesn't use
 > > the shortest forms.
 > 
 > Isn't it true that Exupery uses an intermediate language that looks like
 >      ( mov (eax) ebp )?  I was hoping that I could just do things like
 >      ( add (eax) 1 )        and then look at the output bytes.
 > If I have to know the Smalltalk byte codes first and find one that
 > corresponds to add, and then find the native codes output, then it
 > seems like it would be easier to use masm32 or something to compair
 > the native bytes.
 > 
 > Can you help me with the following two lines from the Intel manuals?:
 > opCode  Instruction              etc
 > 03 /r       ADD r16, r/m16      Valid Valid Add r/m16 to r16.
 > 03 /r       ADD r32, r/m32      Valid Valid Add r/m32 to r32.
 > 
 > this would seem to indicate that the opCode 3 does both the 16 bit case
 > and the 32 bit case.  But as far as I can tell the ModR/M and SIB are
 > identical for 16 and 32 bit cases so the opCode is supposed to differentiate
 > between the two.  How can this be so if the opCode for the 16 bit case is
 > the same as for the 32 bit case?

Depends if the CPU is in real mode (16 bit) or 32 bit protected mode.
It's safe to ignore the 16 bit cases.

Bryce