Hi Steve,
Or rather "... fails becuase *F* is pointing to the old location for
A$(0)".
Ken
On 5/29/18 4:08 PM, Ken Pettit wrote:
Hi Steve,
The line:
20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)
Doesn't work because you take the value of VARPTR(A$(0)) and assign it
to F. But then you assign the value of K. This creates a new scalar
variable, causing A$(0) to be moved. So then the
"256*PEEK(F+2)+PEEK(F+1)" fails because K is pointing to the old
location for A$(0).
If you change your line as follows, then it should work because K is
created first, causing A$() to be moved, and *then* you take the
address of A$():
20 K=0:F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)
Ken
On 5/29/18 3:43 PM, Stephen Adolph wrote:
Ken, when I first read your code I said "That wont work and k(0) will
be wrong."
however it seems to work.
I cannot explain why your code works and my original code did not. I
never modify the string content.
-------------------------------------
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
compared with
20 F=VARPTR(A$(0)):*K(0)*=256*PEEK(F+2)+PEEK(F+1)
yield the same answers for K(0)
-----------------------------------
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
compared with
20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)
yield different answers for K, K(0)
the only difference is using K vs K(0).
I still don't know a good rule for how to safely use VARPTR!!
On Tue, May 29, 2018 at 4:52 PM, Ken Pettit <petti...@gmail.com
<mailto:petti...@gmail.com>> wrote:
Steve,
Are you are trying to pre-calculate the addresses of the strings
to save time or something?
One thing to note is that the address of the A$() or D$() array
variable will move around in RAM. However, as long as you don't
modify the strings *in* the array after they are first assigned,
then the "256*PEEK(K+2)+PEEK(K+1)" address values pointing to the
actual text will NOT change. Those addresses will be pointing
back to the actual string text in the BASIC program (which
doesn't move around during program execution).
This is an optimization BASIC makes. When strings are first
assigned, the variable is created with an address pointing to the
actual string text. The initial value simply points to the BASIC
program. If the contents of that string variable are changed
after that point, then BASIC moves the text into high RAM to make
the modification. Otherwise the text simply lives in the BASIC
program.
So you could create an array of pre-calculated addresses as follows:
10 DIM
A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(3)="blah3"
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
30 REM
40 REM Now any variable can be created and the values in K() will
still be correct.
Ken
On 5/29/18 9:25 AM, Stephen Adolph wrote:
John, I wasn't able to declare variables in any meaningful way
to solve this problem. Only assignment seemed to work. Do you
know a trick for that?
steve
On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis
<jho...@pobox.com <mailto:jho...@pobox.com>> wrote:
On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt
<bir...@soigeneris.com <mailto:bir...@soigeneris.com>> wrote:
>>> Anytime a new scalar (i.e. non-array) variable is
created, the addresses of the array variables must all
change to make room for the new scalar variable.
So BASIC copies all the arrays to a new memory address?
That does not seem very efficient.
Jeff
I think it’s a trade off. Extra levels of indirection are
also inefficient.
It’s either take the hit on a “move” when a variable is
created or take a guaranteed hit every variable access.
And you can avoid the cost by declaring your variables up front.
— John.
