Problems with big CNOP values in AsmPro

8bitbubsy · 19 October 2020, 16:03

I need to place an incbin table at an address that is aligned to 512 bytes, but CNOP in AsmPro seems to fail with values above 8 (?).
Are there any other ways I can make sure that a label's address will be properly aligned to 512 bytes (lower 9 bits all zeroes)?

Code:

     CNOP 0,512
VolTableAligned
     INCBIN voltableS8.bin

hooverphonique · 19 October 2020, 16:30

you could allocate sizeof(voltable)+512 and load/copy the data there starting at the aligned address.

8bitbubsy · 19 October 2020, 16:31

Quote:

Originally Posted by hooverphonique

you could allocate sizeof(voltable)+512 and load/copy the data there starting at the aligned address.

Yeah, that would work, but I first want to see if I can do this on assemble time instead.

ross · 19 October 2020, 16:33

Quote:

Originally Posted by 8bitbubsy

I need to place an incbin table at an address that is aligned to 512 bytes, but CNOP 0,512 in AsmPro seems to not do what it's supposed to do. It seems to fail with values above 8 (?).

Are there any other ways I can make sure that a label's address will be properly aligned to 512 bytes (lower 9 bits all zeroes)?

Code:

     CNOP 0,512
VolTableAligned
     INCBIN voltableS8.bin

Yes if you allocate at memory at run time.

Simply allocate (voltableS8.bin+512-1), then
move.l #VolTableAligned+512-1,d0
and.l #~(512-1),d0
movea.l d0,a0

Ugly? Yes

EDIT: late..

VASM support this CNOP 0,512

8bitbubsy · 19 October 2020, 16:34

Is this seriously the ONLY way to do it? So I either have to waste 256kB of fastmem, or read the table from a file instead...'

EDIT: Would it be posible to use a combination of REPT N + ds.b N + CNOP 0,8 + ENDR?

ross · 19 October 2020, 16:56

Quote:

Originally Posted by 8bitbubsy

Is this seriously the ONLY way to do it? So I either have to waste 256kB of fastmem, or read the table from a file instead...'

EDIT: Would it be posible to use a combination of REPT + ds.b + CNOP + REPE?

Why 256KB waste? 512 bytes and file read.

EDIT: ah ok, in case you embed and copy.

EDIT2: mmh, you can also embed and copy, just over it and moved/aligned to 512

8bitbubsy · 19 October 2020, 16:58

The waste-method would be to have the file incbin'd so that I don't need to read it from file when I copy it to the newly allocated address.

ross · 19 October 2020, 17:06

Quote:

Originally Posted by 8bitbubsy

The waste-method would be to have the file incbin'd so that I don't need to read it from file when I copy it to the newly allocated address.

No, read the EDIT2 above.

move.l #VolTableAligned_BSS,d0
and.l #~(512-1),d0
movea.l d0,a0
lea VolTableAligned_End,a1
move.l -(a1),-(a0)
etc..

at end of the copy (a1) aligned to CNOP 0,512

VolTableAligned
INCBIN voltableS8.bin
VolTableAligned_End
ds.b 512
VolTableAligned_BSS

8bitbubsy · 19 October 2020, 17:30

Code:

	move.l	#VolTable_EndA,d0
	and.l	#~(512-1),d0
	move.l	d0,a0
	lea	VolTable_End,a1
	move.w	#(VOLTAB_LEN/(4*8))-1,d7
.loop	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	dbra	d7,.loop
	move.l	a0,VolTableAligned
	
; [...]

	CNOP 0,4
VolTable
	INCBIN voltableS8.bin
VolTable_End
	ds.b 512
VolTable_EndA

Like this? Anyhow, won't this by shifted by 4 bytes because you decrease a0 first before writing to it?
EDIT: Nevermind, that's how it should be.

ross · 19 October 2020, 17:34

Quote:

Originally Posted by 8bitbubsy

Code:

	move.l	#VolTable_EndA,d0
	and.l	#~(512-1),d0
	move.l	d0,a0
	lea	VolTable_End,a1
	move.w	#(VOLTAB_LEN/(4*8))-1,d7
.loop	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	move.l	-(a1),-(a0)
	dbra	d7,.loop
	move.l	a0,VolTableAligned
	
; [...]

	CNOP 0,4
VolTable
	INCBIN voltableS8.bin
VolTable_End
	ds.b 512
VolTable_EndA

Like this? Anyhow, won't this by shifted by 4 bytes because you decrease a0 first before writing to it?

It is right

Actually you could also use just

and.w #~(512-1),d0

EDIT:
Or use post-increment that is probably faster (but I've also used A2..)

Code:

	move.l #VolTable,d0
	movea.l	d0,a1
	and.w #~(512-1),d0
	movea.l d0,a0
	movea.l d0,a2
	move.w	#(VolTable_End-VolTable)/4-1,d0
.cl	move.l (a1)+,(a2)+
	dbf	d0,.cl

...


VolTable_BSS
	ds.b 512
VolTable
	INCBIN voltableS8.bin
VolTable_End

at end of the copy you have VolTableAligned to CNOP 0,512 in A0

8bitbubsy · 19 October 2020, 17:59

Thanks, it works.

meynaf · 19 October 2020, 18:45

Quote:

Originally Posted by 8bitbubsy

I need to place an incbin table at an address that is aligned to 512 bytes, but CNOP in AsmPro seems to fail with values above 8 (?).
Are there any other ways I can make sure that a label's address will be properly aligned to 512 bytes (lower 9 bits all zeroes)?

There is a good reason for this "limitation". AmigaOS allocates memory that is 8-byte aligned so the assembler can't safely do more than that.

8bitbubsy · 19 October 2020, 19:06

How is this relevant to allocated memory?

meynaf · 19 October 2020, 19:14

When the OS loads your program into memory, hunks can only begin at 8-byte boundaries and therefore anything above cnop 0,8 can't work.

8bitbubsy · 19 October 2020, 19:21

I don't want a hunk to start at a 512-byte boundary, but some data inside it. So all data is split into 8-byte "hunks"?

meynaf · 19 October 2020, 19:25

And if you don't know where the hunk starts - it may start any place 8-byte aligned -, how can you possibly align the data inside ? This is only known when the program is run. The assembler can't do anything about it.

8bitbubsy · 19 October 2020, 19:28

I see. Kinda strange that CNOP 0,512 apparently works in VASM according to ross, then.

meynaf · 19 October 2020, 19:37

It probably does like Phxass, i.e. align relative to the start of the current section.
This will *not* make the final address 512-byte aligned.

Bruce Abbott · 22 October 2020, 09:47

Quote:

Originally Posted by 8bitbubsy

I need to place an incbin table at an address that is aligned to 512 bytes

Why?

8bitbubsy · 25 October 2020, 09:59

Quote:

Originally Posted by Bruce Abbott

Why?

You made me really think about it, and it seems like I maybe don't need this to be aligned anymore. Earlier I was doing something like OR'ing (yes I had my reasons to do this) a value to the address in realtime to get the correct value from the LUT, but I do (An,Dn.w*2) now.

19 October 2020, 16:03	#1
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	Problems with big CNOP values in AsmPro I need to place an incbin table at an address that is aligned to 512 bytes, but CNOP in AsmPro seems to fail with values above 8 (?). Are there any other ways I can make sure that a label's address will be properly aligned to 512 bytes (lower 9 bits all zeroes)? Code: CNOP 0,512 VolTableAligned INCBIN voltableS8.bin Last edited by 8bitbubsy; 19 October 2020 at 16:32.

19 October 2020, 16:34	#5
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	Is this seriously the ONLY way to do it? So I either have to waste 256kB of fastmem, or read the table from a file instead...' EDIT: Would it be posible to use a combination of REPT N + ds.b N + CNOP 0,8 + ENDR? Last edited by 8bitbubsy; 19 October 2020 at 17:01.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
cnop	phx	Coders. Asm / Hardware	13	19 February 2015 21:33
Big Problems in transfering team 17 games !	Vollldo	support.Games	29	22 April 2011 13:35
BIG BIG BIG WINUAE CRASH (with .dmp file included)	The Rom Alien	support.WinUAE	4	31 August 2004 20:26
WinUAE Newbie having big problems please help	Fiery251	support.WinUAE	2	10 September 2001 19:35

19 October 2020, 16:30	#2
hooverphonique ex. demoscener "Bigmama" Join Date: Jun 2012 Location: Fyn / Denmark Posts: 1,624	you could allocate sizeof(voltable)+512 and load/copy the data there starting at the aligned address.

19 October 2020, 16:58	#7
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	The waste-method would be to have the file incbin'd so that I don't need to read it from file when I copy it to the newly allocated address.

19 October 2020, 17:59	#11
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	Thanks, it works.

19 October 2020, 19:06	#13
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	How is this relevant to allocated memory?

19 October 2020, 19:14	#14
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	When the OS loads your program into memory, hunks can only begin at 8-byte boundaries and therefore anything above cnop 0,8 can't work.

19 October 2020, 19:21	#15
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	I don't want a hunk to start at a 512-byte boundary, but some data inside it. So all data is split into 8-byte "hunks"?

19 October 2020, 19:25	#16
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	And if you don't know where the hunk starts - it may start any place 8-byte aligned -, how can you possibly align the data inside ? This is only known when the program is run. The assembler can't do anything about it.

19 October 2020, 19:28	#17
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	I see. Kinda strange that CNOP 0,512 apparently works in VASM according to ross, then.

19 October 2020, 19:37	#18
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	It probably does like Phxass, i.e. align relative to the start of the current section. This will not make the final address 512-byte aligned.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)