i began work on a very similar project... which unfortunately
was rather rapidly shelfed when i entered the professional
programming world, and i had the love of programming damned
near sucked straight out of me. my concept was this, there
are a lot of specialized parallel architechtures out there,
HyperCubes, Maspars, Dataflows, Toroidal Mesh, Vector Scalar,
etc... and SIMD programming of these architechtures had
basically become a very difficult thing to teach, being that
very few universities had access to such awsome specialized
hardware. I felt however that SIMD (Single Instruction
Multiple Data) paradigm programming taught some of the most
valuable skills neccessary in parallel programming.
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 :)
| [reply] |
Use lots of levels of logical abstraction. Extra work in the planning/structure building stage(s) is the best way to ensure that your module will extensible.
Paris Sinclair | 4a75737420416e6f74686572
pariss@efn.org | 205065726c204861636b6572
I wear my Geek Code on my finger.
| [reply] |