Return value issue

[AndyHOvine]

I've not been able to compile the lastest build to check if fixed recently yet (sorry) but this code is storing the value in address $00 and not $02.

Vic 20 code:

var
i,j,k,l: byte at $00;

// ... 

procedure RND();
begin
	
	asm
		
	lda seedhi
	lsr
	rol seedlo
	bcc noeor
	eor #$B4
noeor
	sta seedhi
	eor seedlo
  
	end;
	// result in a
	
end;

begin
// somewhere in my main program ...
addbreakpoint();
k:=RND();
end.

The ASM it produces is:

If I change the var declaration at the top to specify an explicit address for each variable, the problem goes away.

	i: byte at $00;
	j: byte at $01;
	k: byte at $02;
	l: byte at $03;

[leuat]

hm I will need some more information here.. I created a small program that produces random numbers using your method (placing the variables at $02 instead of $00, since that will crash the computer) - and encountered no problems at all..

[leuat]

ah I get it - the value gets stored in $00 since that is where you define your start position of the variables. However, i and j are optimised away since you are not using them - so "k" gets assigned to $00, which will crash the system when set (address 00 is usually reserved for something else on the 6502)

[AndyHOvine]

Ah - that makes sense and explains why the problem has gone away in the same project ... I am now using all those variables, whereas earlier in the project I only had the RND function and had not used all the variables i, j, k and l.

It's just the 6510 in the C64 that is hardwired to ZP $00 and $01 remember, the Vic 20's 6502 is free to use those memory locations.

[AndyHOvine]

And I guess it would not cause a crash or bug in my code (ignoring c64) because i is not used in the code yet.

The only possible issues are:

• confusion for the programmer should they observe this
• if using pointers expecting to see value of k at address 02 and instead it is at address 00

The latter is unlikely. Not a big deal, if easy to fix please do but don't worry if not.

[leuat]

well the only reason this really crashes is because you store the address at "0" and "1", which will result in crashes on 6502 systems.. but I don't want to prevent it because some users might actually want to set the memory configuration through "memcfg : byte at $01" etc. So I'll just close this one =)

[AndyHOvine]

Well the crash is a red herring, best not focus on that part. That only happens on the c64 with that address. But it is fine to close this.

For clarity this was about the effect of the optimisation. If I change the address to $40, the following variables are not guaranteed to be created at 40, 41, 42 and 43 respectively.

i,j,k,l: byte at $40;

If j was not used, k and l would be at a different address. That is the issue.

However, I can resolve by using the at declaration on single variable declarations.

[leuat]

how would you solve this? by not optimising away variables declared at a specific address?

[AndyHOvine]

I guess in this scenario, not optimising an at address variable has zero effect right? It is effectively a statement that says...

You can find i at address 10, j at address 11 etc.

...it doesn't make the program larger by reserving a byte in memory. It also doesn't really make any other issues that I can think of?

So option 1, can we not optimise at addressed vars away?

Or option 2, can we optimise them away but work out the correct address for the others if a predecessor is removed? Ie var i is remove, j is still defined at 11

[leuat]

fixed. went for option 1), any variable with an absolute address will henceforth not be optimised away!