English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 27 August 2019, 12:04   #1
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
VASM vs GNU-AS, syntax differences, elf output, etc.

I've been playing around with Bartman's GCC 8.3 VS Code extension trying to mix C and assembler code, but have become a bit flustered with the GNU assembler's syntax support - it doesn't fully support Devpac style directives and in general doesn't feel nice to use.

Given the amount of work needed to convert existing assembler code to the format gnu as expects, plus the lack of support from other tools for this format (syntax highlighting, etc), I was considering sticking to vasm for my assembly code and letting the GNU tools do the C stuff where they can make a difference.

Has anyone tried to mix and match gcc and vasm like this? I know I'll need to tell vasm to output elf files, but I read that that's possible. Is there any obvious that I might not have considered with this approach?
deimos is offline  
Old 27 August 2019, 21:54   #2
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,479
You are correct. vasm can emit most common object file formats. I haven't checked what this gcc-port needs, but if it is ELF-68k then a simple -Felf option instead of -Fhunk should suffice.

EDIT: Maybe you want to make sure to use the same section names for code, data and bss. I guess gcc calls them ".text", ".data" and ".bss". So you would have to write for example
        section .text,code

for your code section. This is not critical, but allows you to make PC-relative references between C and assembler code.

Last edited by phx; 27 August 2019 at 22:09. Reason: Sections
phx is offline  
Old 27 August 2019, 23:09   #3
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 867
There are 2 programs called mot2mit & mit2mot but it's not ideal.
nogginthenog is offline  
Old 28 August 2019, 11:01   #4
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by phx View Post
You are correct. vasm can emit most common object file formats. I haven't checked what this gcc-port needs, but if it is ELF-68k then a simple -Felf option instead of -Fhunk should suffice.

EDIT: Maybe you want to make sure to use the same section names for code, data and bss. I guess gcc calls them ".text", ".data" and ".bss". So you would have to write for example
        section .text,code

for your code section. This is not critical, but allows you to make PC-relative references between C and assembler code.
Thanks. I'm going to try a few experiments by hand before trying to integrate it with my makefile.

One thing that concerns me is that I've read that elf doesn't support specifying that sections should be loaded into chip memory. Right now that's not a big deal, but could prove inconvenient later.
deimos is offline  
Old 28 August 2019, 11:07   #5
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by nogginthenog View Post
There are 2 programs called mot2mit & mit2mot but it's not ideal.
Thanks, I'll file that bit of information away in case I can't get other approaches to work.

Gnu-as also a --mri switch to accept source in MRI syntax, which might be worth me looking at, but I can't find any documentation on that syntax to find whether it's close to Devpac.
deimos is offline  
Old 28 August 2019, 13:52   #6
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,479
Quote:
Originally Posted by deimos View Post
One thing that concerns me is that I've read that elf doesn't support specifying that sections should be loaded into chip memory.
Right. The Chip-attribute can only survive in hunk-format.

You could work around the problem by using a linker which supports both, hunk- and ELF-objects. Write your assembler sources as hunk-objects and your C sources as ELF-objects. Then link them together into the final hunk-format executable. A simple example:
Code:
vlink -bamigahunk -o myprog cobj1.o cobj2.o asmobj1.o asmobj2.o
Although this may become complicated with thousands of references to all kinds of gcc-specific libraries and startup codes, and maybe there are even hidden features which only the GNU-linker knows. So no guarantee.

You may have better success by only doing the final link stage with vlink and try to resolve all gcc-specific references with GNU-ld first. The -r option usually writes a new relocatable object file, suitable for the next linking pass. But you might still need a proper startup code in the final stage:
Code:
m68k-gnu-ld(or whatever it is called) -r -o cobjs.o cobj1.o cobj2.o ... -lmylibs...
vlink -bamigahunk -o myprog startup.o cobjs.o asmobj1.o asmobj2.o
That's just the theory. I never used a gcc-version higher than V5.
phx is offline  
Old 28 August 2019, 14:25   #7
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by phx View Post
Right. The Chip-attribute can only survive in hunk-format.

You could work around the problem by using a linker which supports both, hunk- and ELF-objects. Write your assembler sources as hunk-objects and your C sources as ELF-objects. Then link them together into the final hunk-format executable. A simple example:
Code:
vlink -bamigahunk -o myprog cobj1.o cobj2.o asmobj1.o asmobj2.o
Although this may become complicated with thousands of references to all kinds of gcc-specific libraries and startup codes, and maybe there are even hidden features which only the GNU-linker knows. So no guarantee.

You may have better success by only doing the final link stage with vlink and try to resolve all gcc-specific references with GNU-ld first. The -r option usually writes a new relocatable object file, suitable for the next linking pass. But you might still need a proper startup code in the final stage:
Code:
m68k-gnu-ld(or whatever it is called) -r -o cobjs.o cobj1.o cobj2.o ... -lmylibs...
vlink -bamigahunk -o myprog startup.o cobjs.o asmobj1.o asmobj2.o
That's just the theory. I never used a gcc-version higher than V5.
Ok, thanks, but I think this is getting a bit too much for me. Maybe I'll try getting the gnu assembler to accept Devpac style sources with minimal changes and disable fast memory until I'm more comfortable with the build process, or until more people have tried this new GCC 8.3 / VS Code integration.
deimos is offline  
Old 28 August 2019, 15:13   #8
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,479
Quote:
Originally Posted by deimos View Post
Ok, thanks, but I think this is getting a bit too much for me.
Sorry when I confused you. I just tried to show you an option to use real Chip-memory sections. Otherwise you don't need anything else than the -Felf switch on vasm.

Quote:
Maybe I'll try getting the gnu assembler to accept Devpac style sources with minimal changes and disable fast memory
Even if that works, you would still have the same result as when calling vasm with -Felf (besides that vasm is really Devpac-compatible, can do optimisations, etc.).
phx is offline  
Old 28 August 2019, 15:52   #9
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by phx View Post
Sorry when I confused you. I just tried to show you an option to use real Chip-memory sections. Otherwise you don't need anything else than the -Felf switch on vasm.

Even if that works, you would still have the same result as when calling vasm with -Felf (besides that vasm is really Devpac-compatible, can do optimisations, etc.).
Baby steps...

As there is already some support code build that came with the integration that builds with the gnu assembler, which I'd like to keep, I've got to rework the makefile to build my stuff separately. I've had a go at that and have tried building my code with the gnu --mri option. The syntax changes at first glance don't look bad, but it fails if you have white space after commas, in "dc.w 3, 2", for instance, so I'm abandoning that, and I'm going to try plugging in vasm with -Felf.

If that works I might come back to your suggestions, but as the debugger integration works only with elf files (I believe), it may be as a separate entry in the makefile so that I can build for debugging or build for release. I don't yet fully understand how the integration works.
deimos is offline  
Old 29 August 2019, 11:53   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,479
Quote:
Originally Posted by deimos View Post
gnu --mri option. The syntax changes at first glance don't look bad, but it fails if you have white space after commas, in "dc.w 3, 2", for instance, so I'm abandoning that, and I'm going to try plugging in vasm with -Felf.
As far as I remember white spaces in operands aren't allowed in Devpac either. You would need the -spaces option in vasm to allow that.
phx is offline  
Old 29 August 2019, 12:58   #11
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by phx View Post
As far as I remember white spaces in operands aren't allowed in Devpac either. You would need the -spaces option in vasm to allow that.
I did not know that.

I've just looked at the Makefile for the code I'm trying to move over, and it includes the -phxass option, which allows blanks in operands.

I need to put spaces after commas. I can't not do it.
deimos is offline  
Old 29 August 2019, 13:35   #12
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,479
Quote:
Originally Posted by deimos View Post
I've just looked at the Makefile for the code I'm trying to move over, and it includes the -phxass option, which allows blanks in operands.
Yes. -phxass includes -spaces. So you are not looking for a Devpac-compatible assembler after all, but PhxAss compatible.

Quote:
I need to put spaces after commas. I can't not do it.
phx is offline  
Old 29 August 2019, 13:53   #13
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by phx View Post
Yes. -phxass includes -spaces. So you are not looking for a Devpac-compatible assembler after all, but PhxAss compatible.
At this point I'm going to admit that I have no idea how my current sources are written, I don't remember the origin of the makefile I've been using, and when things worked I didn't question it.

I'm going to stick with vasm and fix my code to conform to one true standard. In your opinion, should this be "-devpac -spaces" or "-phxass", or neither?
deimos is offline  
Old 29 August 2019, 14:49   #14
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,479
Quote:
Originally Posted by deimos View Post
I'm going to stick with vasm and fix my code to conform to one true standard. In your opinion, should this be "-devpac -spaces" or "-phxass", or neither?
That's a matter of taste. If you think that white spaces in your operands make them more readable, then you should do that. You may even use -spaces with -devpac.

I regard Devpac as a kind of reference assembler, so vasm is really close to Devpac in its default setting. -devpac can be used for stricter compatibility. The differences are listed here (last section: Devpac compatibility) in detail:
http://sun.hasenbraten.de/vasm/index.php?view=tutorial

I think the biggest differences are that Devpac doesn't optimise by default and automatically aligns all data.
phx is offline  
Old 29 August 2019, 19:20   #15
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 441
Quote:
Originally Posted by phx View Post
That's a matter of taste. If you think that white spaces in your operands make them more readable, then you should do that. You may even use -spaces with -devpac.

I regard Devpac as a kind of reference assembler, so vasm is really close to Devpac in its default setting. -devpac can be used for stricter compatibility. The differences are listed here (last section: Devpac compatibility) in detail:
http://sun.hasenbraten.de/vasm/index.php?view=tutorial

I think the biggest differences are that Devpac doesn't optimise by default and automatically aligns all data.
Thanks. I'll aim for Devpac compatibility, but with extra spaces and manually aligned data. That should get me close enough to good.
deimos is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
vasm chip section and a.out output module krustur Coders. Asm / Hardware 5 09 June 2019 21:56
gnu objectdump as disassembler bebbo Coders. General 0 14 April 2019 18:07
GNU GAS Immediate data misbehaving MintyTheCat Coders. Asm / Hardware 14 03 January 2016 17:01
Preparing a CF from GNU/Linux iddqd support.FS-UAE 1 21 June 2015 11:09
Elf - Ocean's Elf - could do with an update. MethodGit project.WHDLoad 9 28 August 2013 19:50

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08301 seconds with 15 queries