hi,
you have two problems really - in the first problem it is how to actually
allocate the data. A way commonly used for stack variables is to have the
'compiler' keep a running total of how much stack space is being used by the
function as it is compiling (or by allocating the space in a separate phase
after the function compilation), along with offsets from some base registers
(such as EBP) where each variable is stored. So ALL the space used by the
function is allocated up front, and the compiler decides on offsets from a
base register that will be used to index the variables.
with a little more work, you could have it allocate things dynamically on the
stack in different memory scopes and then index off say the stack pointer
itself, this becomes a matter of how to keep track of what is going on at
compile time. Doing that could 'move' the offsets of other variables that
were previously declared, depending on how you do it. It would mainly be a
matter of appropriate bookeeping at compile time to do this, but it
complicates things somewhat and will especially make writing a debugger
harder.
The other problem is really determining whether to take an address literally
or to do a pointer indirection on that address to find the real address -
again that is a bookeeping issue and depends on the structure of the source
language. In 'c' an array such as char myarray[10] always consideres myarray
to be a literal address... but an array defined as a pointer such as char
*myarray assumes the pointer has to be 'indirected' from the actual address of
the myarray variable (e.g. by the equivalent of loading the destination
address value from the memory location of the variable). The compiler is
designed to handle both situations because this is what the semantics of the C
language call for. If creating a new language, you really need to just make
some rules about what the semantics are in terms of what is literal and what
is a pointer, then design around them.
in general, the library functions in the C language such as strcpy and printf
are the same all the time, and such concerns as to what the actual address of
the data is are handled in the compiled code prior to calling the specified
function (by indirecting as appropriate).
David
"news.tkdsoftware.com" wrote:
> What I understand is that I can allocate strings in two ways, either on
> the stack or on the heap.
>
> By allocating a string on the stack, the string's fixed size has to be
> aligned by the size of the stack. For example, a 16-bit wide stack
> would mean that a 30 byte string would need 8 slots on the stack.
> Now, lets saying I wanted to define a variable of fixed size 30,
> assign a string value to it and then print it. The equivalent C code
> would be:
>
> char szText[30];
> strcpy(szText, "Hello World");
> printf(szText);
>
> How should I handle pushing the string onto the stack and referencing
> it when it comes time to print it?
>
> The other alternative is heap allocation. In this case, only 1 slot is
> required because it is going to reference the variable that is a memory
> address pointer on the heap. Again, how would the stack & referencing
> of the string be handled when it comes time to print it?
>
> I'm thinking that in both scenarios, the store(strcpy) and print(printf)
> operations will need to be slighly different as one is working with a
> pointer to heap memory and the other is working with a value that is
> referenced directly on the stack, right?
>
> --
>
> "news.tkdsoftware.com" <> wrote in
> message news: m...
> > Aside from comp.compilers, is there any other forum, newsgroup or medium
> > where I can post questions concerning the development of a byte code
> > compiler & virtual stack machine?
> >
> > --
> >
> >
> >
|
Similar Threads
