|Jump tables and OOP in Oberon firstname.lastname@example.org (1996-07-13)|
|Re: Jump tables and OOP in Oberon email@example.com (Tim Dwyer) (1996-07-18)|
|Re: Jump tables and OOP in Oberon firstname.lastname@example.org (1996-07-22)|
|Re: Jump tables and OOP in Oberon email@example.com (1996-07-23)|
|Re: Jump tables and OOP in Oberon firstname.lastname@example.org (Darius Blasband) (1996-07-23)|
|From:||email@example.com (Ram Meenakshisundaram)|
|Date:||13 Jul 1996 22:00:41 -0400|
|Organization:||BlackRock Financial Management Inc.|
Hi Compiler Gurus,
I am in the process of writing an Oberon Compiler. Since, I only took
the basic compiler course for my Undergraduate and Graduate studies, we
did not do much on pascal-type case statements. We implemented the case
statement as if it was one large IF-THEN-ELSIF statement. We briefly talked
about jump tables. Can someone clearly define how jump tables are used in
pascal-type CASE statements? Are there any algorithms to generate case
statements in the most optimal way. Are there any C/C++ code out there that
implements case statements via jump tables?
Also, Oberon has an IS statement that returns TRUE or FALSE if a variable
is inheriated from a particular type. That is if variable x is of type C and
type C is inheriated by type A, then the following would return true:
How can this be implemented the most efficent way? I was think about creating
a pointer for each Object. Each pointer Object will point to its parent.
Each Object variable would have a pointer to its Object pointer. To determine
if a variable is of type X, one only needs to traverse through the object
tree and see if the variable's object pointer is the same as the one specified
in the IS command. The only problem I can see with this implementation is
that it requires:
(z + 1) * 4 bytes, for each Object type defined and z is the number of
variables declared as that Object.
Thanks for the info....
BlackRock Financial Management Inc
Phone: (212) 754-5577
Return to the
Search the comp.compilers archives again.