VASM assert directive

[hop]

But then I would would be unaware of the potential for optimisation if the size changed to another power of 2

[hop]

It looks like adding an ASSERT outside of a section can result in the creation of an extra, empty CODE section.

test.s:

SCREEN_WIDTH_PIXELS	EQU	320
	SECTION	code
	rts

Assembling with

vasmm68k_mot -Fhunk test.s

Gives

vasm 1.9a (c) in 2002-2022 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.5a (c) 2002-2022 Frank Wille
vasm motorola syntax module 3.15e (c) 2002-2022 Frank Wille
vasm hunk format output module 2.14 (c) 2002-2022 Frank Wille

code(acrx2):               2 bytes

but

SCREEN_WIDTH_PIXELS	EQU	320
	ASSERT SCREEN_WIDTH_PIXELS!=0,"Invalid width"
	SECTION	code
	rts

built with the same command line gives:

vasm 1.9a (c) in 2002-2022 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.5a (c) 2002-2022 Frank Wille
vasm motorola syntax module 3.15e (c) 2002-2022 Frank Wille
vasm hunk format output module 2.14 (c) 2002-2022 Frank Wille

CODE(acrx1):               0 bytes
code(acrx2):               2 bytes

Is this expected behaviour?

[phx]

It's not great, but to be expected. An

assert

directive creates an "atom" of the type ASSERT, similar to DATA, INSTRUCTION, LABEL or OPTS atoms. In vasm a section is a list of atoms, which will be processed in multiple passes.

Which means: an atom cannot exist outside of a section. When there is no section once the parser runs into an atom-generating directive, then the default section will be created.

EDIT: In your example you may think this is not required, which is correct, as the symbol is absolute and already known when the parser meets the directive. But assertions also have to work with labels, where the value is not known or correct until the final pass.

[hop]

Originally Posted by phx

It's not great, but to be expected.

Thanks for the explaination. Not sure if it is worth making a note of this in the docs next to the description of the assert directive.

It looks like the empty CODE section does not result in an empty hunk when either vasm or vlink is used to generate the executable.

[phx]

Originally Posted by hop

Not sure if it is worth making a note of this in the docs next to the description of the assert directive.

Fixing it is not much more work than describing the current sad state. So I prefered to improve the situation.

Solution: a few kinds of atoms may be worth to save in an intermediate container, before I add them in front of the first real section. You may try tomorrow's snapshot.

Besides ASSERT there are also other directives, like PRINTT, PRINTV, ECHO, FAIL, etc. which could wait until a section exists. Adapted the code for all these directives.

Other atoms, like data, instruction or label still start the default section, of course, if you didn't specify one.

It looks like the empty CODE section does not result in an empty hunk when either vasm or vlink is used to generate the executable.

That's a feature of the selected output module from vasm. The Hunk and ELF output modules automatically remove empty sections, unless you specified

-keepempty

.

[hop]

Originally Posted by phx

Fixing it is not much more work than describing the current sad state. So I prefered to improve the situation.

Solution: a few kinds of atoms may be worth to save in an intermediate container, before I add them in front of the first real section. You may try tomorrow's snapshot.

Great. Hope there are no complications. I'll test this out.

Originally Posted by phx

That's a feature of the selected output module from vasm. The Hunk and ELF output modules automatically remove empty sections, unless you specified

-keepempty

.

Thanks - I'd always forget to look in the output module docs. I can see

-keepempty

in vasm.pdf but not in vlink.pdf

[hop]

Originally Posted by phx

Fixing it is not much more work than describing the current sad state. So I prefered to improve the situation.

Solution: a few kinds of atoms may be worth to save in an intermediate container, before I add them in front of the first real section. You may try tomorrow's snapshot.

I build today's snapshot, and seems to be working great. Thanks very much.

Before:

vasm 1.9a (c) in 2002-2022 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.5a (c) 2002-2022 Frank Wille
vasm motorola syntax module 3.15e (c) 2002-2022 Frank Wille
vasm hunk format output module 2.14 (c) 2002-2022 Frank Wille

CODE(acrx1):	           0 bytes
code(acrx2):	           2 bytes

After:

vasm 1.9a (c) in 2002-2022 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.5c (c) 2002-2022 Frank Wille
vasm motorola syntax module 3.16 (c) 2002-2022 Frank Wille
vasm hunk format output module 2.14a (c) 2002-2022 Frank Wille

code(acrx2):	           2 bytes

[phx]

Thanks for testing.

Originally Posted by hop

I can see

-keepempty

in vasm.pdf but not in vlink.pdf

vlink doesn't remove empty sections automatically. You need option

-gc-empty

for it.

BTW, I just implemented

-wfail

into vlink, as requested.

[hop]

Originally Posted by phx

Thanks for testing.


vlink doesn't remove empty sections automatically. You need option

-gc-empty

for it.

Thanks for implementing, and thanks for the tip.

Originally Posted by phx

BTW, I just implemented

-wfail

into vlink, as requested.

Great! I don't think I'm seeing this in the latest daily source snapshot

26 Jun 2022 02:15:18 UTC: vlink.tar.gz (238896 bytes)

C:\tmp>vlink -Wfail
Warning 2: Unrecognized option '-Wfail'.
Fatal error 6: No input files.
Aborting.

When I download this file it is 1,054,720 bytes in size. Not sure if it's pulling down the wrong file, or if the changes haven't made it in yet. Is a changelog available anywhere? Thanks

EDIT: Found the

history

file and can see -wfail mentioned in there. Let me try again...
EDIT: Coming through now human error...

[hop]

Originally Posted by phx

I just implemented

-wfail

into vlink, as requested.

Thanks for this. It is great for making builds more robust.

It caught me out the first time I tested it because I was expecting an error message.

C:\amiga-dev\target\loaders\hunk_to_rawseg>vlink -brawseg -q -Thunk_to_rawseg_loadfile.ld -nowarn=12 -wfail -o intermediates\hunk_to_rawseg_loadfile.rawseg intermediates\hunk_to_rawseg_loadfile || EXIT /B 1
Warning 22: Attributes of section .chip were changed from r-x- to rwx- in hunk_to_rawseg_loadfile.

C:\amiga-dev\target\loaders\hunk_to_rawseg>

The build script was exiting on fail and could (should?) print its own own custom message, but it might be nice for the developer if the tool could itself output a line to stderr (possibly a new internal error) to state that it had stopped on a warning because warnings were treated as errors.

This is the MS compiler output in a similar circumstance:

1>C:\amiga-dev\host_tools\src\HunkHelpers.cpp(50,11): error C2220: the following warning is treated as an error
1>C:\amiga-dev\host_tools\src\HunkHelpers.cpp(50,11): warning C4189: 'numBytes': local variable is initialized but not referenced
1>Done building project "HunkLoad.vcxproj" -- FAILED.

I guess the vlink equivalent would be:

C:\amiga-dev\target\loaders\hunk_to_rawseg>vlink -brawseg -q -Thunk_to_rawseg_loadfile.ld -nowarn=12 -wfail -o intermediates\hunk_to_rawseg_loadfile.rawseg intermediates\hunk_to_rawseg_loadfile   || EXIT /B 1
Warning 22: Attributes of section .chip were changed from r-x- to rwx- in hunk_to_rawseg_loadfile.
Fatal error 150: Warnings treated as errors
Aborting.
C:\amiga-dev\target\loaders\hunk_to_rawseg>

But I guess this would require a refactor to make warnings generate an internal error when -wfail is used.

Please just tell me to GTFO if I'm being pedantic, or confusing -wfail with -Werr and giving you unnecessary work. Great toolchain!

[phx]

As you wish.
Done.

[hop]

Originally Posted by phx

As you wish.
Done.

Wonderful thanks.

Warning 22: Attributes of section .chip were changed from r-x- to rwx- in hunk_to_rawseg_loadfile.
Error 152: Warnings treated as errors.

[Tigerskunk]

What does ASSERT exactly do and how is it useful?

[hop]

Originally Posted by Tigerskunk

What does ASSERT exactly do and how is it useful?

It provides build-time error checking. It is better to catch problems as early as possible. Bugs can be fixed much faster if the assember tells you there is a problem right after you make the edit, rather than have a bug in your code which causes a crash or corruption at runtime that can be difficult and time-consuming to debug.

It is similar in principle to the C++

static_assert

. See this Stack Overflow post for more info.

In assembly programs, I often use ASSERT make the assember check (assert) that the size of some

DC.B

or

DC.W

or

INCBIN

data matches the required size.

For example if I was declaring a table of 8 values

table: 
	DC.B $00,$01,$03,$04,$05,$06,$07
	ASSERT*-table==8,"Expect 8 bytes in table"

Note that here

*

is the address of the current location in the file. Think of it like the 68000 PC, but at assembly time. So

*-table

is the measured size of the table at assembly time (end-start)

When assembled this would error with:

error 48 in line 94 of "proc.s": assertion "*-table==8" failed: Expect 8 bytes in table
>       ASSERT*-table==8,"Expect 8 bytes in table"

And could quickly be fixed by adding the missing value.

This also works for externally incbined data:

table: 
	INCBIN "table.bin"
	ASSERT*-table==8,"Expect 8 bytes in table"

The assember can also perform maths for you, so you could confirm that the number of words in a 16x16 pixel 2-bitplane sprite was correct:

sprite: 
	DC.W $444C, $5401 ; Control words
	DC.W $5555, $3333 ;First line of 16 pixels
	DC.W $1234, $5678 ;Second line
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W $1234, $5678
	DC.W 0, 0 ; End
	ASSERT (*-sprite)/2==2+(16*2)+2

The left hand side of the assert is calculating the number of words of data defined. The right hand side is calculating the expected number of words of data: 2 control words at the start + 16 lines of two words each + 2 control words at the end.
A line was missing - so when assembled, vasm reports:

error 48 in line 109 of "proc.s": assertion "(*-sprite)/2==2+(16*2)+2" failed:
>       ASSERT (*-sprite)/2==2+(16*2)+2

Here's another real world example. Check that the size of the imported image matches the size expected by the code.

LOGO_WIDTH_PIXELS	EQU	176
LOGO_HEIGHT_PIXELS	EQU	114
	ASSERT LOGO_WIDTH_PIXELS&7==0,"Logo image width is not an integral number of bytes"
LOGO_WIDTH_BYTES	EQU	LOGO_WIDTH_PIXELS>>3
	ASSERT LOGO_WIDTH_BYTES&1=0,"Logo image width is not an integral number of words"
LOGO_WIDTH_WORDS	EQU	LOGO_WIDTH_BYTES>>1
...
; some blitting later on
	move.w	#SCREEN_WIDTH_BYTES-LOGO_WIDTH_BYTES,BLTDMOD(a5)
	move.w	#(LOGO_HEIGHT_PIXELS<<6)+LOGO_WIDTH_WORDS,BLTSIZE(a5)	; start the blitter
...
	SECTION	data_c,data,chip
	EVEN	; word align for blitting
logo:	INCBIN	"logo.raw"
logoSizeBytes EQU *-logo
	PRINTT "Logo size, bytes:"
	PRINTV logoSizeBytes
	ASSERT logoSizeBytes==LOGO_WIDTH_BYTES*LOGO_HEIGHT_PIXELS*BITPLANE_COUNT

[hop]

Originally Posted by phx

Hard to explain. A combination of enough new features or important bug fixes, and the feeling that it has been sufficiently tested.

Hi. Thanks again for implementing the ASSERT directive. I make heavy use of it and couldn't live without it. It would be great if it could be released into the wider community so they could benefit too (and I wouldn't have to manage locally built exes )

I am finding it very handy for constructing disk images:

        include "DiskGeometry.i"

	ORG 0           ; Put VASM in absolute mode. See https://eab.abime.net/showpost.php?p=1542178&postcount=4

	INCBIN "Build/bootblock"
	PRINTT "Bootblock size (bytes):"
	PRINTV *
	ASSERT *<=BOOTBLOCK_SIZE_BYTES,"Bootblock code exceeds max bootblock size of $400 (1024) bytes"  ; Requires pre-release version of VASM. See https://eab.abime.net/showpost.php?p=1542732&postcount=14

	PRINTT "Bootblock bytes free:"
	PRINTV BOOTBLOCK_SIZE_BYTES-*

        ....

	ORG 12*TRACK_SIZE_BYTES 
	INCBIN "disk1.adf",12*TRACK_SIZE_BYTES,148*TRACK_SIZE_BYTES

	PRINTT "Disk image size (bytes):"
	PRINTV *
	ASSERT *==DISK_SIZE_BYTES,"Expect disk image to be $DC000 (901120) bytes" ; Requires pre-release version of VASM. See https://eab.abime.net/showpost.php?p=1542732&postcount=14

	END

[paraj]

FWIW I usually use something like

  ifne *-8
  error assumptions changed!
  endc

for asserts, but it'd probably be nice with dedicated syntax even if it isn't portable

[phx]

That's what I am usually doing as well. But conditional assembly doesn't work in all cases, because it must evalulate the expression during the first pass. The ASSERT directive creates an atom in the section, which is evaluated in the final pass with the final values.

Example, this doesn't work with IF:

a:      move.l  #sym,d0
b:      rts
        if      b-a!=2
        fail    "not optimized"
        endc
sym     =       1

But with ASSERT it does:

a:      move.l  #sym,d0
b:      rts
        assert  b-a==2,"not optimized"
sym     =       1

[hop]

I like the way asserts keep the assertion positive, rather than having to negate it. Double negatives often mix me up!