On 10/16/08, bryce@kampjes.demon.co.uk bryce@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?
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?
Bryce _______________________________________________ Exupery mailing list Exupery@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery