Assembly differences between PNut and Flexgui

JGM · 2020-05-01 17:39

Hi,

I noticed a difference between the instructions generated when using PNut v34r and flexgui 4.1.7. When assembling the following:

DAT
		ORG

loop		drvnot		# 56
		waitx		## 25_000_000/20
		jmp		# loop

PNut assembles the last line to: 00 00 80 FD
flexgui ssembles the last line to: F0 FF 9F FD

The difference is in the form of jmp used. PNut is using ”JMP D” while Flexgui is
using “JMP #{\}A”.

Changing the program to:

DAT
		ORG

loop		drvnot		# 56
		waitx		## 25_000_000/20
		jmp		#\ loop

PNut compiles the last line to: 00 00 80 FD
flexgui compiles the last line to: 00 00 80 FD

Now both of them use ”JMP D”. Is there a right and wrong here?

cgracey · 2020-05-01 17:54

I think PNut should assemble a relative jump, not an absolute jump. I will look into this shortly.

cgracey · 2020-05-01 23:33

Well, this is weird. My PNut_v34r.exe is compiling it differently than you are seeing:

TYPE: CON VALUE: 00000000 NAME: CLKMODE_
TYPE: CON VALUE: 01312D00 NAME: CLKFREQ_
TYPE: DAT_LONG VALUE: 00000000 NAME: LOOP

CLKMODE: $00000000
CLKFREQ: 20,000,000
XINFREQ: 0

Hub bytes: 16

00000- 5F 70 64 FD 89 09 80 FF 1F A0 65 FD F0 FF 9F FD '_pd.......e.....'

The the last four bytes show a relative jump. How can this be?

rogloh · 2020-05-01 23:39

Is the space after the # causing any difference?

ozpropdev · 2020-05-01 23:51

Pnut V34r seems Ok here.
My debugger shows

00000: fd64705f                  DRVNOT  #$38
00001: ff800989                  AUGD    #989 (131200)
00002: fd65a01f                  WAITX   ##$1312d0
00003: fd9ffff0                  JMP     #$ffff0 (rel)

cgracey · 2020-05-02 00:34

rogloh wrote: »

Is the space after the # causing any difference?

It doesn't make any difference.

rogloh · 2020-05-02 00:38

I wonder if JGM has any control chars or differences in his source code that don't show up in the pasted text example? Not sure otherwise how there could be a different outcome if JGM is using the exact same version of the tools, unless this is a mistake...?

Tubular · 2020-05-02 01:03

Are you running Pnut on the mac somehow, JGM? I remember you had some fun and games installing things somewhat manually. Not that it should really make a difference...

JGM · 2020-05-02 03:02

Tubular wrote: »

Are you running Pnut on the mac somehow, JGM? I remember you had some fun and games installing things somewhat manually. Not that it should really make a difference...

I am running it in a virtual machine using an ancient OS (parallels with windows XP). It does run without complaint however. I took all tabs and extra spaces out so that the program looks like this:

DAT

loop drvnot #56
 waitx ##25_000_000/20
 jmp #loop

Doing that I get this list file:

TYPE: CON             VALUE: 00000000          NAME: CLKMODE_
TYPE: CON             VALUE: 01312D00          NAME: CLKFREQ_
TYPE: DAT_LONG        VALUE: FFF00000          NAME: LOOP


CLKMODE:   $00000000
CLKFREQ:  20,000,000
XINFREQ:           0


Hub bytes:          16

00000- 5F 70 64 FD 89 09 80 FF 1F A0 65 FD 00 00 80 FD   '_pd.......e.....'

I guess I will stick with flexgui for now.

JGM · 2020-05-02 03:14

rogloh wrote: »

I wonder if JGM has any control chars or differences in his source code that don't show up in the pasted text example? Not sure otherwise how there could be a different outcome if JGM is using the exact same version of the tools, unless this is a mistake...?

I am running PNut in a virtual machine but I am confused about how that might make a difference. When I select "about" from the help menu, the dialog that appears indicates that it is version 34r. The program was entered in PNut so there shouldn't be any funny invisible characters or weird line endings. For now I am just going to stick to flexgui.

cgracey · 2020-05-02 03:26

I don't know what could trigger such a bug. The carry flag is used to differentiate relative vs absolute. Maybe the x86 simulator on the Mac isn't properly executing the '386 code in the compiler.

Ariba · 2020-05-02 04:54

JGM wrote: »

...

DAT

loop drvnot #56
 waitx ##25_000_000/20
 jmp #loop

Doing that I get this list file:

TYPE: CON             VALUE: 00000000          NAME: CLKMODE_
TYPE: CON             VALUE: 01312D00          NAME: CLKFREQ_
TYPE: DAT_LONG        VALUE: FFF00000          NAME: LOOP


CLKMODE:   $00000000
CLKFREQ:  20,000,000
XINFREQ:           0


Hub bytes:          16

00000- 5F 70 64 FD 89 09 80 FF 1F A0 65 FD 00 00 80 FD   '_pd.......e.....'

With the code above, I get same output as you (an absolute jump).
If I insert a org after DAT, I get a relative jump.
If I insert a orgh instead of org, I get again the absolute jump.
That is with PNUT on real Windows 7.

Andy

cgracey · 2020-05-02 05:12

I see what's happening.

The initial address is $00000 and ORGH mode is set, not ORG mode. When the jump to $00000 is assembled, it sees that the destination address is within cog space, not hubexec space, but it's in hubexec (ORGH) mode. So, it thinks it's going to cross from hubexec to cogexec, and therefore needs to use an absolute address to bridge from hub to cog space.

You need to ORGH $400, at least, to get into hubexec space. That will solve the problem. What you have here is a pure PASM file, not a Spin2 file.

ozpropdev · 2020-05-02 06:55

The original post had code with ORG which works as expected.

JGM · 2020-05-03 01:14

ozpropdev wrote: »

The original post had code with ORG which works as expected.

Chip is right, I did drop the ORG in the original post when I ran on PNut. For completeness sake I methodically tested three cases and picked up another difference between PNut and flexgui as shown in the first case below. They both encode the same instruction but the addresses are different in bits 10 thru 19. All 1's versus 0's. Huh?

DAT
	ORGH $400
loop	drvnot #56
	waitx ##25_000_000/20
	jmp #loop

This results in the last line assembling to:
PNut: F0 03 90 FD
Flexgui: F0 FF 9F FD

DAT
	ORG 0
loop	drvnot #56
	waitx ##25_000_000/20
	jmp #loop

This results in the last line assembling to:
PNut: F0 FF 9F FD
Flexgui:F0 FF 9F FD

DAT
	
loop	drvnot #56
	waitx ##25_000_000/20
	jmp #loop

This results in the last line assembling to:
PNut: 00 00 80 FD
Flexgui:F0 FF 9F FD

cgracey · 2020-05-03 05:37

In practice, you would use an ORG for cog code or an ORGH $400+ for hub code, so this is not a practical case, I think. It's ambigious.

evanh · 2020-05-03 05:48

Chip,
The first one, with ORGH $400, is also screwy. Only 10 of the 20 bits filled for the offset.

JGM · 2020-05-03 06:23

cgracey wrote: »

In practice, you would use an ORG for cog code or an ORGH $400+ for hub code, so this is not a practical case, I think. It's ambigious.

Omitting the ORG was definitely an error on my part in the original post. I am more confused by the differences in the instructions generated when I include ORGH $400. If I understand correctly, my syntax is correct but the instructions generated are different between PNut and Flexgui. I just ran it again and can verify that I am seeing F0 03 90 FD from PNut and F0 FF 9F FD from Flexgui.

evanh · 2020-05-03 06:42

It's a regression I'd say. Pnut didn't used to do this.

ozpropdev · 2020-05-03 07:53

Here's some more tests that might give a clue to the issue.

dat	orgh	$400

loop	drvnot	#56
	waitx	##25_000_000
	jmp	#loop		'<-- F0 03 90 FD wrong!
	jmp	#$		'<-- FC FF 9F FD  Correct

'00400- 5F 70 64 FD BC BE 80 FF 1F 80 64 FD F0 03 90 FD   '_pd.......d.....'
'00410- FC FF 9F FD                                       '....'

now consider this change that inserts padding.

dat	orgh	$400

loop	drvnot	#56
	waitx	##25_000_000
	long	0[253]		'<-- pad with nops
	jmp	#loop		'<-- F0 FF 9F FD Correct
	jmp	#$		'<-- FC FF 9F FD Correct

'00800- 00 00 00 00 00 00 00 00 00 00 00 00 F0 FF 9F FD   '................'
'00810- FC FF 9F FD                                       '....'

Note how much padding I had to insert before things started compiling correctly.

evanh · 2020-05-03 10:13

Hmm, just a different wrong!

EDIT: It's off by $400 bytes I think. Which would also explain JGM's example.

Roy Eltham · 2020-05-03 10:23

I recall another thread talking about orgh ignoring the address after it. Cluso, I think, was complaining about it to Chip, who I think said it was working as intended.

ozpropdev · 2020-05-03 10:36

ORGH addresses are only ignored in pasm+spin2 source.

evanh · 2020-05-03 10:40

This one must be new. It's completely broken right now.

cgracey · 2020-05-03 10:41

Roy Eltham wrote: »

I recall another thread talking about orgh ignoring the address after it. Cluso, I think, was complaining about it to Chip, who I think said it was working as intended.

In Spin2 mode, ORGH $400 will set the origin to $400, but assemble the code at the current address, which changes as objects are nested together.

I need to look into this bug of filling only the bottom 10 bits of address.

Today I discovered a bug where nested bitfields are not compiling correctly. This is delaying the parser I want to post.

evanh · 2020-05-03 11:24

cgracey wrote: »

I need to look into this bug of filling only the bottom 10 bits of address.

I now think that was illusion. The destination looks to be incorrectly offset by +$400. Which creates a positive relative branch until the loop back distance exceeds that offset. Only then do you see all 20 bits filled. It's still branching to the wrong destination though.

ozpropdev · 2020-05-03 23:40

@cgracey
Went back to earlier Pnit versions and issue starts appearing from Pnut V34n if that helps.

cgracey · 2020-05-04 00:02

ozpropdev wrote: »

@cgracey
Went back to earlier Pnit versions and issue starts appearing from Pnut V34n if that helps.

This was when I adopted the guidelines presented by Evanh, which made sense (at that time, anyway).

I need to find out what it's doing wrong now.

evanh · 2020-05-04 05:07

Oh bother, that's a while back. Thinking about it, I don't think I ever retested your changes at the time ...

EDIT: Ah, that's not the case at all. It was back in early February and still a v33 Pnut - https://forums.parallax.com/discussion/comment/1488890/#Comment_1488890

And if I try to run my LOC bug test code from a v34r assembled, it outright crashes in the hubexec section.

evanh · 2020-05-04 06:22

Pnutv34L is the last one that works for me. v34m crashes in the hubexec.

cgracey · 2020-05-04 12:17

evanh wrote: »

Pnutv34L is the last one that works for me. v34m crashes in the hubexec.

Evanh, would you mind posting or pointing to an example of how it's erring? I haven't experienced any trouble, so I must be missing it.

Assembly differences between PNut and Flexgui

Comments