Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter

chris.cranford@tkdsoftware.com (Chris Cranford)
28 Apr 2004 14:36:37 -0400

          From comp.compilers

Related articles
Basic-Like PCODE Compiler and Virtual Host/Interpreter chris.cranford@tkdsoftware.com (2004-04-15)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter tdk@thelbane.com (Timothy Knox) (2004-04-21)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter bonzini@gnu.org (2004-04-21)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter lex@cc.gatech.edu (Lex Spoon) (2004-04-21)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter alex@iliasov.org (2004-04-21)
Basic-Like PCODE Compiler and Virtual Host/Interpreter chris.cranford@tkdsoftware.com (2004-04-21)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter chris.cranford@tkdsoftware.com (2004-04-28)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter chris.cranford@tkdsoftware.com (2004-04-28)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter kenrose@tfb.com (Ken Rose) (2004-04-28)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter freitag@alancoxonachip.com (Andi Kleen) (2004-04-28)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter arargh404@NOW.AT.arargh.com (2004-04-29)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter alex_mcd@btopenworld.com (Alex McDonald) (2004-05-02)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter thp@cs.ucr.edu (2004-05-08)
[2 later articles]
| List of all articles for this month |
From: chris.cranford@tkdsoftware.com (Chris Cranford)
Newsgroups: comp.compilers
Date: 28 Apr 2004 14:36:37 -0400
Organization: TKD Software, Inc.
Keywords: interpreter
Posted-Date: 28 Apr 2004 14:36:37 EDT

> Start with lex and yacc (or flex and bison) and put together a lexical
> scanner and a parser, working towards producing a recognizer for Basic
> syntax. No semantic analysis, in other words
> ...
> It helps a lot that you don't have in practice to do any memory management
> in this tool, just allocate everything and have it deleted at the end of
> the program.


But that is what keeps confusing me I believe. Integer code makes
sense to me because the integer values are simply stored as 32-bit
values on a stack which is a 32-bit wide slot. :-). Lets take a
string based example and address my two questions which has me
puzzled:


The first case would be where I would consider using the stack to hold the
contents of a string, such as:


    Dim s as String * 25
    s = "Some Text here"


Since the variable s is known to always be of size 25 (24 chars plus nul),
then the variable can be allocated directly on the stack just like it would
in a C/C++ program with the following statement:


    char s[25];
    strcpy(s, "Some Text here");


But where do we get "Some Text here" string? Encode it in the OPCODE
stream itself or should I have a serialized "data block" that the VM
reads from the BYTECODE file at interpreter time that contains these
types of constant values such as strings, external function names,
etc? Since I could store strings as 16-bit UNICODE characters, 2
characters would fit into a 32-bit wide stack. Should I code it to
store 2 characters per stack slot or consider only using 1 stack slot
per character to keep it simple?


Second case with strings would be something like:


    Dim s as String = "Init text here"


This implies that s can be of any length and thus to avoid having to
resize the stack all the time, it makes since to create s in the heap
and only put the allocated heap address on the stack, right?


I think once I can get past these questions and grasp an understanding
of best to implement strings, it will easily lend itself to being able
to understand how to best handle other data types like:


    - user defined types
    - external DLL function call references
    - arrays


> To implement internal functions (such as print or str$), you can have a
> "primative" bytecode whose argument is an id number for the function.


Correct, therefore the number of opcodes can be kept at a minimal. I
was considering such a scenario in the case where I need to be able to
make external API stdcalls to functions for example in KERNEL32.DLL.


I do want to point out that I really appreciate you offering the code
snippets and examples. It definately helps a ton! I just need to
grasp how to handle things like strings, arrays, and UDTs and I should
be all set.


Thus far, my BISON/FLEX files parse my language and using printf()
calls, simply spits out messages to stdout about what it finds.
Otherwise, I need to link it into generating the actual symbol table
and syntax trees which I hope won't be too confusing ;-).


Thanks in advance!
Chris


Post a followup to this message

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