Help with virtual assembler design (Leonid Tombak)
Sun, 30 Jan 1994 01:41:20 GMT

          From comp.compilers

Related articles
Help with virtual assembler design (1994-01-30)
Re: Help with virtual assembler design (1994-01-31)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Leonid Tombak)
Keywords: design, assembler, question, comment
Organization: University of Wollongong, NSW, Australia.
Date: Sun, 30 Jan 1994 01:41:20 GMT

Hello! We are developing a portable system. So we have our own language
which we then translate to some virtual assembler. Then assembler
statements are implemented in C. For example :

The statement : a = 5 is interpreted


Then each statement is in general just a C-function. Of course we are not
satisfied with one address assembler and certainly it is easy to go to the
3-address assembler.

I know there is a lot of systems which uses the same principles. Does
anybody knows the literature which describes the new ideas in this area or
any already implemented systems with description of such internal
assembler. It looks like the more statements of virtual assembler you have
the more faster your system will work. But we don't want to have some
chaos assembler so if anybody can recommend us the literature about the
subject it will be very helpfull. Now we have some time to think what we
actually want to design which is quite rare thing in industrial
programming. Thanks in advance.

Sincerely yours
Leonid Tombak.
[The last time I did something like this, one address code seemed to be
the way to go. If you're building hardware, registers are clearly faster
than a stack, but in an interpreted system, the main performance goal
seems to me to be to reduce interpreter overhead, usually by having a
large set of high level operators so you spend more time doing the
operators and less time going from one operator to another. This is
reminiscent of the late 1960's approach which bought us overimplemented
Vax architecture, but in this case, minimizing instruction counts actually
makes sense. As an independent issue, you should consider threaded or
indirect-threaded code to speed up the interpreter loop. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.