Re: Bison/Flex To ByteCode

From: Chris Cranford (chris.cranford_at_tkdsoftware.com)
Date: 04/15/04 

Date: Thu, 15 Apr 2004 06:40:41 -0400

On 4/15/2004 6:23 AM, KBUCHEGG@GASCAD.AT wrote to ALL:

First, thank you for taking the time to answer my question instead of just
saying to go t oo a compiler newsgroup. Kudos!

Secondly, everything you said makes perfect since. So the goal of my
BISON/FLEX files will be to verify the syntax and push operations and
data onto the necessary stacks which can then be populated OFF, eval.
and the OPCODE/data stored to a disk file. Right?

Now, here comes the questions as you probably assumed there would be:

1. From your explaination, I would assume there are 2 stacks my compiler
   needs to maintain while parsing the SOURCE language file. One for
   maintaining the commands and the second for data associated with the
   commands/opcodes performed, right?

2. Now, lets assume for the moment I need to implement something like a
   very SIMPLISTIC print statement where there is no concatenation, etc.
   In BASIC, equal to a PRINT "Hello World" and C printf("hello world\n").
   How would this instruction get handled and represented on a stack
   machine? I would assume in this case a memory management system is
   necessary? ... that is unless my compiler takes each character of a
   string and translates it to it's literal integer equivalent and then
   integers get pushed to the stack with a special opcode that simply
   says PTOS (pop top of stack) and append it to a memory location where
   we are creating the string on the fly. Right?

3. Then when I want to get fancier by introducing variables, care to
   show an example of what COULD be done?

If I am starting to see the clearer picture, what my VM is really going
to become is an entire CPU with registers, memory management subsystem,
and a special set of OPCODES and a STACK of instructions/data by which
it operates, just like my Intel chip, right?

-> Seriously. You start with defining what your VM looks like. What
-> instructions
-> or understood by your VM (what action has to be performed on what code,
-> the OpCodes).
-> Example: You write an expression parser. For simplicity I often define
-> the VM to be a stack machine, thus I don't have to deal with register
-> allocation on the compiler. This expression parser deals with addition
-> only, no variables, numbers are integers with 2 bytes each, high byte first
->
-> Your VM eg. then could interpret the opcodes (all numbers are hex)
->
-> 01 push the number following the OpCode on the stack
-> 02 add 2 numbers from the stack and push the result on the stack
-> 03 display the topmost number from the stack
->
-> when your compiler sees the statement
->
-> 2 + 5
->
-> it generates the opcode sequence
->
-> 01 00 02 01 00 05 02 03
->
-> That would be the machine code for the above 'program' for your particular
-> VM.
-> In 'assembler' syntax this would read
->
-> address opcode memnonic
-> **********************************
-> 0000 01 00 02 push 2
-> 0003 01 00 05 push 5
-> 0006 02 add
-> 0007 03 display_tos
->
-> [cut for breavity]
->
-> Continuing with this, you will want to add multiplication, division, etc.
-> Depending on how mighty you want your VM to be, you will also want to add
-> jump instructions, call instructions, comparisons, conditonal jumps,
-> increment,
-> decrement operations. Whatever you want. If your VM includes an opcode for
-> creating a window, well, so be it. You are the designer, you design your own
-> CPU (at least at the logical level :-).

Thanks,
Chris
 

Relevant Pages

  • Re: Bison/Flex To ByteCode
    ... > saying to go t oo a compiler newsgroup. ... where functions push and pop operate on the number stack managed by the VM ... I would eg. probably introduce an OpCode ... Thats the whole point behind Java. ...
    (comp.lang.cpp)
  • Re: .Net applications, not optimized for CPU at all?
    ... Both Java VM and MSIL are logically stack machines. ... while the MSIL instructions aren't. ... This implies that all the usual compiler tricks can be applied. ...
    (borland.public.delphi.non-technical)
  • Re: Forth Research Topics
    ... efficiently than the ZPU. ... since instructions have to be multi-cycle. ... the C compiler to control a CPU stack instead of registers. ...
    (comp.lang.forth)
  • Re: Seymour remembered
    ... > manage to get a loop into this buffer, ... I wasn't certain from the article which Fortran compiler they were ... Instructions were 15, 30, or 60 bits long so theoretically the stack ...
    (comp.lang.fortran)
  • Re: Forth Research Topics
    ... that is what seems to make the ZPU a bit clunky ... since instructions have to be multi-cycle. ... The internal data stack would be used as register space. ... the C compiler to control a CPU stack instead of registers. ...
    (comp.lang.forth)