My program reads a file to determine how big to make a dynamic array.
If I put this part of the code in a separate subroutine HLA fails me with subject message.
I understand the problem. Is there a way out?
Here is a trivial example:

program Dynam;
#include ( "C:\hla\include\stdlib.hhf" )
type dType: array.dArray( string, 1 );
const sizIt := 10;
var It: dType;
procedure dAllocIt;
begin dAllocIt;
array.daAlloc( It, sizIt ); //<-- Fails here
end dAllocIt;
begin Dynam;
dAllocIt(); // <------------------Use it here
array.daFree( It );
end Dynam;

The failure is at "array.daAlloc( It, sizIt ); "
The error message is
Macro called in file "Dyn.hla" at line 8
Non-local name requires a base register.
Near: << It >>
Posted on 2003-02-09 10:23:32 by benanne12
Variable It is declared as local to the program itself, so it is placed on stack and cannot be referenced directly. Declare it as a static variable.
Posted on 2003-02-10 03:15:05 by clone-d
Thanks. That did the trick.
Coming from a PL/I background--where dynamic (i.e., controlled ) variables are a different animal from static and automatic ( like var) --and where automatic variables are simply created at procedure activation (and don't go on the environment stack) I forgot that even main var variables are on the stack. Thanks again.
Posted on 2003-02-10 05:08:14 by benanne12
I thought it will be possible to use _display_ to access this variable like this:
Undefined intermediate ID.

Near: << It >>


clone-d.
Posted on 2003-02-10 07:58:30 by clone-d

My program reads a file to determine how big to make a dynamic array.
If I put this part of the code in a separate subroutine HLA fails me with subject message.
I understand the problem. Is there a way out?
Here is a trivial example:

program Dynam;
#include ( "C:\hla\include\stdlib.hhf" )
type dType: array.dArray( string, 1 );
const sizIt := 10;
var It: dType;
procedure dAllocIt;
begin dAllocIt;
array.daAlloc( It, sizIt ); //<-- Fails here
end dAllocIt;
begin Dynam;
dAllocIt(); // <------------------Use it here
array.daFree( It );
end Dynam;

The failure is at "array.daAlloc( It, sizIt ); "
The error message is
Macro called in file "Dyn.hla" at line 8
Non-local name requires a base register.
Near: << It >>



Well, Intermediate variables don't quite work that way.
They need to be indexed by a 32-bit register (typically EBX).
Here's the code that "should have" worked:



program Dynam;
#include ( "stdlib.hhf" )
type
dType: array.dArray( string, 1 );

const
sizIt := 10;

var
It: dType;

procedure dAllocIt;
begin dAllocIt;

mov( _display_[0], ebx );
array.daAlloc( ebx:It, sizIt ); //<-- Fails here

end dAllocIt;

begin Dynam;

dAllocIt(); // <------------------Use it here
array.daFree( It );

end Dynam;



However, due to a bug in the array.daAlloc package (actually, it's a bug
in the HLA compile-time language that I've known about for a long time
and won't be able to fix until HLA v2.0 for technical reasons), the "ebx::It"
parameter causes the whole thing to choke. There are two specific solutions
I can give for your problem:

1) since you're declaring the variable in the main program, there is really
no need to allocate it on the stack. Make it static; this works just fine:



program Dynam;
#include ( "stdlib.hhf" )
type
dType: array.dArray( string, 1 );

const
sizIt := 10;

static
It: dType;

procedure dAllocIt;
begin dAllocIt;

array.daAlloc( It, sizIt );

end dAllocIt;

begin Dynam;

dAllocIt(); // <------------------Use it here
array.daFree( It );

end Dynam;



The other solution is to pass the variable as a parameter by reference.


In theory, you should also be able to do this because your procedure
has no local variables and no parameters:



program Dynam;
#include ( "stdlib.hhf" )
type
dType: array.dArray( string, 1 );

const
sizIt := 10;

var
It: dType;

procedure dAllocIt; @noframe;
begin dAllocIt;

array.daAlloc( ebp::It, sizIt );
ret; // Must have return, since it's no frame.

end dAllocIt;

begin Dynam;

dAllocIt(); // <------------------Use it here
array.daFree( It );

end Dynam;


However, this breaks for the same reason as the original code.
Still, the @noframe and EBP::xxxxx trick is one that I employ all the
time when accessing intermediate variables one lex level up.
Randy Hyde
Posted on 2003-02-10 22:52:14 by rhyde