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

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


<snip>
>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:
Actually, in all the Basic's that I have seen, 's' would be 25 chars
and no nul.
>
> char s[25];
> strcpy(s, "Some Text here");
>
>But where do we get "Some Text here" string?
String constants generally live in a string constant area.


>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?
MS VB uses UNICODE chars, BCET (which I wrote) does not.


>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?
In that case, 's' would be a variable length string, and 's' would be
the string descriptor, and the string would live in the string pool.


<snip>


If you want to see how I handled this situation, get a copy of BCET
(2nd URL) and try things. One of the outputs is an assembler file.


--
Arargh404 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

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