[<<][staapl][>>][..]
Mon Aug 25 10:28:07 CEST 2008

interoperation and snarfing

Yes, finding a nice to have the project survive is difficult.  Maybe
it is better to start focussing on using 3rd party tools.  As
mentioned in the last post: the only real reason to write an assembler
is to also write a simulator.  Doing this without machine readable
processor descriptions is asking for trouble.  I had this idea a few
weeks ago about writing an instruction extractor that snarfs directly
from the vendor-specified assembler, to extract opcodes when
addressing modes are provided.  Maybe a similar thing could be done
with semantics?  Run tethered programs to see how each instruction
behaves, which flags it sets etc..  There are ways to make this not a
completely manual unverified "copy from manual" story.

However, this is a road that needs focus, so it might be a better idea
to avoid it, and start using vendor assemblers, and forget about the
simulator idea.

About simulation: the difficulty is not necessarily to simulate
processor cores, but to simulate peripherals.  Without help from the
manufacturer, this is really not doable.

So.. It looks like processing text files is going to be part of the
problem.  I need to have a look at the Ometa parser language.  This
might come in handy for integration work: use grammars not parsers.



[Reply][About]
[<<][staapl][>>][..]