Compile issues using PhxAss

[NovaCoder]

Hiya,

I'm trying to compile the following assembler file (which I didn't write BTW) using PhxAss.

It seems to be having trouble with the global variable declarations which have arithmetic applied to them at declaration time....like these ones:

__farbss equ _aliastransform-$f0 line 94
_r_drawsurf_surf equ _r_drawsurf+8 line 738
vid_colormap equ _vid+4 line 740


Any ideas how to fix this?

[NovaCoder]

This is interesting, I think I may have stumbled across a solution...

patch	macro
;;	move.l	d1,(\1-_c2p8start+4,a0)	; This fails because of bug in PhxAss
	movea.l	#\1-_c2p8start,a1		; so try this way instead.
	move.l	d1,4(a0,a1.l)
	endm

[phx]

Originally Posted by NovaCoder

__farbss equ _aliastransform-$f0 line 94
Any ideas how to fix this?

PhxAss is unable to process imported symbols (xref) in an EQU directive. That's sad but fact.

If you're not coding on an extremely resource-limited system, like an A500, I would always recommend to upgrade to vasm (http://sun.hasenbraten.de/vasm/ ).

[phx]

Originally Posted by NovaCoder

    move.l    d1,(\1-_c2p8start+4,a0)    ; This fails because of bug in PhxAss

This works for me with V4.40. Both labels, \1 and _c2p8start, have to be defined locally in your current source, though. Otherwise the expression is illegal, on all assemblers, because no relocation exists which can represent such an operation in an object file.

[NovaCoder]

Ok thanks Frank, I'll give VSAM another go then. Last time I tried it I had some issues linking to my C/C++ project, I'll let you know if I have any issues.

[Don_Adan]

PhxAss is fast, but has some bugs, from my memory don't handle "/" sign correctly.
F.e, you can assemble next line and check results under ReSource:

dc.b '////////'

[phx]

You probably mean the '\' character, not '/'.

'\' is used as an escape-character, like in C. And vasm inherited this feature from PhxAss in its default mode. It can be disabled in vasm by entering Devpac-compatibility mode (-devpac option).

[Don_Adan]

Originally Posted by phx

You probably mean the '\' character, not '/'.

'\' is used as an escape-character, like in C. And vasm inherited this feature from PhxAss in its default mode. It can be disabled in vasm by entering Devpac-compatibility mode (-devpac option).

I can check it again, but I'm almost sure that problem occured for "/" sign. From my tests for PhxAss every dc.b '//" is converted to single "/" sign. And for me this is buggy, due it can cause problems (unexepected by author) after assembling source. From my memory PhxAss don't like similar code too:

dc.l (BuffyEnd-Buffy)/4
Buffy ds.b 128
BuffyEnd

I don't use Vasm, meynaf told me that is too slow.
Some from my game sources are assembled many (over 20) minutes even for 68040, for 68000 and Devpac are assembled over 4 hours and 20 minutes.

[NovaCoder]

Hiya Frank,

How do you run the Amiga Output module? http://sun.hasenbraten.de/vasm/release/vasm.html

I tried 'vasm c2p_file.s -o c2p_file.o -m=68060 -databss' but that came up with and error message 'unknown option 'databss'

I assume I need to specify 'databss' otherwise I won't able to link the object file to my Amiga C project like I do with PhxAss?

I tired downloading the files from the VASM site but I had the same problem as last time (I couldn't unpack them on my system).

[phx]

Originally Posted by NovaCoder

I tried 'vasm c2p_file.s -o c2p_file.o -m=68060 -databss' but that came up with and error message 'unknown option 'databss'

Did you read the first sentence of chapter 12 (amiga output format)?

This chapter describes the AmigaOS hunk-format output module which can be selected with the `-Fhunk' option to generate objects and with the `-Fhunkexe' option to generate executable files.

The -databss makes only sense for executable files, though. So it only works with -Fhunkexe.

I assume I need to specify 'databss' otherwise I won't able to link the object file to my Amiga C project like I do with PhxAss?

No, this is not required.
The option will just remove zero-words at the end of a section (which is only supported since OS2.0).

I tired downloading the files from the VASM site but I had the same problem as last time (I couldn't unpack them on my system).

The binary or the source archive? You have a bad tar or gzip?

[phx]

Originally Posted by Don_Adan

I can check it again, but I'm almost sure that problem occured for "/" sign. From my tests for PhxAss every dc.b '//" is converted to single "/" sign.

No, this works. I just tried that again. You certainly mean '\\'.

From my memory PhxAss don't like similar code too:
dc.l (BuffyEnd-Buffy)/4
Buffy ds.b 128
BuffyEnd

That's right. PhxAss has big problems with operations on label differences. As PhxAss is restricted to two passes, it needs to backpatch the code when optimizations between labels takes place later, which gets very complicated. It's a design bug, which can never be fixed.

I don't use Vasm, meynaf told me that is too slow.
Some from my game sources are assembled many (over 20) minutes even for 68040, for 68000 and Devpac are assembled over 4 hours and 20 minutes.

But vasm is portable! You could assemble your game sources on a GHz machine in a second.

[NovaCoder]

Originally Posted by phx

Did you read the first sentence of chapter 12 (amiga output format)?
The -databss makes only sense for executable files, though. So it only works with -Fhunkexe.

No, this is not required.
The option will just remove zero-words at the end of a section (which is only supported since OS2.0).

I tried just 'vasm c2p_file.s -o c2p_file.o -m=68060' which produced a file but I could not link to it using gcc

Exactly the same assembler source file produces a file using PhxAss that I can link successfully with so something is not working right for me with VASM.

Originally Posted by phx

The binary or the source archive? You have a bad tar or gzip?

I tried to download this file -> http://sun.hasenbraten.de/vasm/downl...asmm68k_mot.gz

And cannot open the archive no matter which program I use (Windows 7).

[phx]

Originally Posted by NovaCoder

I tried just 'vasm c2p_file.s -o c2p_file.o -m=68060' which produced a file but I could not link to it using gcc

Seems you were not any more successful in reading my last reply than you were reading the documentation.
You cannot expect the assembler to generate Amiga hunk format output, when you don't select it! Use the -Fhunk option!

And cannot open the archive no matter which program I use (Windows 7).

*Sigh*
Works fine for everybody else. Just install gzip:
http://www.gzip.org/
Or use a real operating system.

[NovaCoder]

Originally Posted by phx

Works fine for everybody else. Just install gzip:
http://www.gzip.org/
Or use a real operating system.

It doesn't even unzip under AmigaOS, how real do you want to get

[prowler]

Originally Posted by phx

*Sigh*
Works fine for everybody else. Just install gzip:
http://www.gzip.org/
Or use a real operating system.

NovaCoder is correct; the vasmm68k_mot.gz file is not in gzip format or it's damaged (I'm using gzip 1.3.12).

[PeterK]

This file is indeed compressed in gzip format, but you will need a decompressor which is able to decode the advanced 7z compression. On my PC I can do this successfully with WinRAR or 7-Zip, of course. The analysis from universal unextractor is this:

Collecting data from file: vasmm68k_mot.gz
100.0% (.Z/GZ/GZIP) GZipped File (3000/1)
7-Zip gzip compressed file ...

[phx]

Hmm... now I'm getting worried. You all do really have problems with that gzip format do you?

I checked it again on a real 68k Amiga (running OS3.1), using gzip 1.2.4 from Aminet: http://aminet.net/util/pack/gzip124x2.lha

gzip -d vasmm68k_mot.gz

worked for me. Strange. I don't understand what is wrong.

The original file on the web-server is compressed by NetBSD's gzip. It may have been highest compression level, but it shouldn't use 7z.

frank@sun cd /var/www/vasm/download/vasm_M68k_motorola/1.5b/AmigaOS3_68k/
frank@sun file vasmm68k_mot.gz 
vasmm68k_mot.gz: gzip compressed data, was "vasmm68k_mot_os3", from Unix
frank@sun gzip --version
NetBSD gzip 20040830

[pintcat]

Tested with gzip 1.2.4 on Amiga OS3.9 (not the one phx pointed to, but this here: http://aminet.net/package/dev/gg/gzip-bin) - works fine.
Tested with gzip 1.3.12 on Linux - works fine too.

[meynaf]

Originally Posted by NovaCoder

Hiya,

I'm trying to compile the following assembler file (which I didn't write BTW) using PhxAss.

It seems to be having trouble with the global variable declarations which have arithmetic applied to them at declaration time....like these ones:

__farbss equ _aliastransform-$f0 line 94
_r_drawsurf_surf equ _r_drawsurf+8 line 738
vid_colormap equ _vid+4 line 740


Any ideas how to fix this?

It assembles without errors if you use SET directive instead of EQU, like this :

__farbss set _aliastransform-$f0

[NovaCoder]

That's interesting, thanks for that