Below is the sequence of 9 tests of the picoLARC AssemblerLisp's
ability to generate machine code. My hat is off to the person who
suggested using ollydbg to generate the codes that can then be
tested against. That really made things a lot easier. I seem to be
able to understand machine code a l
I think you could simplify your testing by writing the output from a
sequence of tests to a binary file.
Then use a command line assembler (like nasm) to assemble source code
with the same desired output.
Then simply compare the binary files, if they differ, try to find where
they differ (with a
WOOHOO :) I've been wishing for something like this for about two
months now...
Julian.
On 08/11/2008, at 7:42 AM, Kjell Godo wrote:
I hope that in this way I can make a live documentation in Smalltalk
that shows how all the Intel machine codes work.
Any help would be highly appreciated.
Once all the addressing modes for 32 bits are squared away then somebody
will have to go down the list of opcodes in the Intel manual and make a
Class for each one. The compiled addressing Eval is searched to see what is
in it and then the opCode is selected.
If you know how to make these tools work off the top of your head could you
help me a little? I don't know anything about executable file formats. I
conjecture that flat file is what I want. Since Udo tells CodeX to generate
flat file in his Dolphin inline assembler.
nasm ... ??? <---[ is it do
On Sat, 2008-11-08 at 15:29 -0800, Kjell Godo wrote:
> If you know how to make these tools work off the top of your
> head could you help me a little? I don't know anything about
> executable file formats. I conjecture that flat file is what I want.
> Since Udo tells CodeX to generate flat file i
