So what I began, was the construction of a retargettable
emulator of sorts. It read a series of configuration files
that gave it the opcodes, the intstruction set, the
interconnection network, the API, etc... and basically, in
a series of files, you could describe any parallel architechture
and implement it in software... (and have students program
for these "parallel architechtures")
The way I approached this was simple, I approached it from
a very OO manner, there are a series of "tool" in a modern
microprocessor which are universal accross damned near all
architechtures (from registers (or accumulators, depending
where you are), to timers, to clocks, to pipelines, etc...)
and I defined a series of interfaces for abstract interfaces
into these "chunks" of the processor. From then, I subclassed
each one of the parent classes into a specific incarnation
of a technology (abstract registers became 32 bit registers,
etc...) and set up the ties. Eventually based on a series
of subclasses and opcode logic instruction files, i was able
to emulate one of the processors on a maspar MP-1 to about
40% reliability, but around then is when I gave up.
In a situation like this, you may want to study the way that
other processor "tools" like disassemblers have been written,
the way that they represent the opcodes, the instruction
sets, the optimization and the pipelines. From there, I
would create a series of abstract classes that implemented
commonalities in an easily inheritable aspect, and then,
i would go from there... (for the implementation of
opcodes and instruction sets, may i suggest you invest your
time learning formal grammers and look into the Parse::RecDescent
module, to make your life easier?)
Wow... that was much longer than I invisioned it being... I hope it helps! And if not, hell, you got what you paid for :)
In reply to Re: Writing a disassembler
by eduardo
in thread Writing a disassembler
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |