Problems with ASM6809

Hardware Hacking, Programming and Game Solutions/Cheats
Post Reply
pser1
Posts: 1235
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Problems with ASM6809

Post by pser1 » Fri Feb 08, 2019 10:12 pm

Hi Ciaran,
I have compiled 122 AGD games so far and have never had compilation problems, but now I have a program that gets this kind of messages:

Code: Select all

Assemble: ROUST1
error: ROUST1.ASM:9118: value of 'k00089' unstable
error: ROUST1.ASM:9125: value of 'k00127' unstable
error: ROUST1.ASM:9141: value of 'k00211' unstable
error: ROUST1.ASM:9142: value of 'Evnt11' unstable
error: ROUST1.ASM:9153: value of 'l00052' unstable
error: ROUST1.ASM:9164: value of 'l00111' unstable
I suspect it has to be related to the macro I added to force the conditional jumps to be always 'the best' so that it uses
short branches most of the time. I copy here the macro I am using for maybe you could see if it contains a 'hidden' bug

Code: Select all

CONDJMP	MACRO
	IF	(((\2 - *) >= 0) && ((\2 - *) <= 131)) || (((* - \2) > 0) && ((* - \2) <= 126))
			fcb	com_\1
			fcb	\2 - * - 1
	ELSE
		IF (\1 == "bra")
			fcb	$16
		ELSE
			fcb	$10,com_\1
		ENDIF
			fdb	\2 - * - 2
	ENDIF
			ENDM
The macro is called that way:

Code: Select all

        cmpa 11,y
        CONDJMP "bne", a00108
I was forgetting that te macro depends on this table:

Code: Select all

com_bra	equ	$20
com_brn	equ	$21
com_bhi	equ	$22
com_bls	equ	$23
com_bcc	equ	$24
com_bhs	equ	$24
com_bcs	equ	$25
com_blo	equ	$25
com_bne	equ	$26
com_beq	equ	$27
com_bvc	equ	$28
com_bvs	equ	$29
com_bpl	equ	$2a
com_bmi	equ	$2b
com_bge	equ	$2c
com_blt	equ	$2d
com_bgt	equ	$2e
com_ble	equ	$2f
Any advice would be very appreciated
Thanks in advance
pere

pser1
Posts: 1235
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Problems with ASM6809

Post by pser1 » Fri Feb 08, 2019 10:31 pm

Hi,
I have added before the first CONDJMP that creates an error:
rzb 127
That way, I force the compiler to use long branch. Compiling again the program, the problem arises some code lines below.
I have done this four times and finally got a binary that works flawlessly.
This seems to point to the macro CONDJUMP as culprit for these 'dancing addresses', but I cannot spot the error.
cheers
pere

sixxie
Posts: 1073
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Problems with ASM6809

Post by sixxie » Sat Feb 09, 2019 11:46 am

I'd probably have to see the specific code to work out just what's going on, but to help reason about it:

The 'unstable' error is raised when, during any pass, a symbol is assigned a value different from what it had on the previous pass. Normally this just triggers another pass (to allow things to "settle"), but there's a cap on the number of passes (10), and if it still hasn't settled by then you'll see the error.

For the first pass, any forward references will be asking to evaluate undefined symbols. This also triggers another pass, but for the sake of evaluation returns zero. From the point of view of your branch, zero is likely both small and far away, so it'll pick the long form. On subsequent passes, where a value is known, the short form may be preferred. It's almost certainly possible to create a pathological case where the shortening causes subsequent instructions to get shorter too and trigger the 10 pass limit, but I've never seen it in real code.

But it's probably also possible to cause it to oscillate between two sizes... Can't come up with an example offhand...

One note: I can see why you're comparing against 131 in that first test where the more "correct" number would be 129 - accounting for the shorter form taking less space - but I think special-casing "BRA" there (and using 130?) might be useful.

Sorry I can't be of more help. This is a feature I kinda want to add to asm6809 itself, but it's a tricky problem, and while I have ideas, I've not had the time to experiment with them. Implementing it in macros is going to be unreliable because of that "undefined equates to zero" aspect (though yes, real code probably isn't going to be close enough to zero for it to be an issue).

pser1
Posts: 1235
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Problems with ASM6809

Post by pser1 » Sat Feb 09, 2019 2:59 pm

Hello Ciaran,
thanks for your fast answer!
I thought I had already answered to this message, but it seems I dind't send it :-(
This 'strange' case has happened only with the last AGD game I was trying to convert to 6809.
The authors of this game are asking for a small fee to the users that want to play it, so I have asked permission
to them in order to put the source here ...
I have been searching among my sent-received mails for maybe I could find your email address, but failed!
If you could allow me to send it to you via normal email, I'd do as soon as posisble!
Thanks in advance
pere serrat
psergm@gmail.com

pser1
Posts: 1235
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Problems with ASM6809

Post by pser1 » Sat Feb 09, 2019 3:12 pm

I have been changing the values inside the macro so that the long branch is taken most of the time.
I have reduced both compares to 100 instead of 131 or 127
The result ... the problem arises the double of times than originally :-(
And of course much above/sooner in the code source.

cheers
pere

pser1
Posts: 1235
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Problems with ASM6809

Post by pser1 » Sat Feb 09, 2019 5:20 pm

Hi Ciaran,
just wanted to thank you for the fast support you are offering to ASM6809 users.
The new version works flawlessly, so we are going to update the AGD toolchain with it
cheers
pere

sixxie
Posts: 1073
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Problems with ASM6809

Post by sixxie » Sat Feb 09, 2019 5:38 pm

For those of you watching in black & white, it turned out that it was fixable just by upping the maximum number of passes asm6809 would take trying to settle the addresses (lots of forward references with code changing sizes between passes). I'll try and make that a command-line option in future...

Post Reply