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

"Alex McDonald" <alex_mcd@btopenworld.com>
2 May 2004 21:52:41 -0400

          From comp.compilers

Related articles
[5 earlier articles]
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)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter Postmaster@paul.washington.dc.us (Paul Robinson) (2004-05-24)
Re: Basic-Like PCODE Compiler and Virtual Host/Interpreter kenrose@tfb.com (Ken Rose) (2004-05-30)
| List of all articles for this month |
From: "Alex McDonald" <alex_mcd@btopenworld.com>
Newsgroups: comp.compilers
Date: 2 May 2004 21:52:41 -0400
Organization: BT Openworld
References: 04-04-075
Keywords: interpreter
Posted-Date: 02 May 2004 21:52:41 EDT

"Chris Cranford" <chris.cranford@tkdsoftware.com> wrote
> 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");


Why keep it on the stack; would a 32 bit pointer to the string not be
more appropriate? If you need to strongly type the stack, keep a
parallel stack whose value is datatype of the stack entry; or use 2
stack locations for each type, the first the type, the second the
value (although that might be messier).


You'll run into trouble with most modern x86 OSes trying to store the
string on the stack. For instance, Windows allocates a real memory
page to the stack only when the virtual page _below_ the current page
is referenced (stacks on Intel grow down, or "right to left"), and
your strings will therefore be limited to 4k if you address them from
"left to right" (that is, up in stack terms). Otherwise you'll get
errors.


> 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?


If you just keep a pointer to the string, you can use a "push-and-jump"
technique. For this you need a bytecode that


1. fetches the offset of the next valid bytecode
2. pushes the address of the string on the stack
2. adjusts the bytecode instruction pointer by adding the amount fetched in
(1).


Then the string is in the bytecode stream, as in


| push-and-jump | 17 | "14 byte string" | <next bytecode> | ... |
^
IP


Or


| push-ptr | <ptr to string> |


Same principle.


>
> 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?
>


Or just a 32 bit ptr to the string...


--
Regards
Alex McDonald


Post a followup to this message

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