Volker Barthelmann's/Frank Wille's VASM assembler for the JRISC

[JagChris]

The assembler 'VASM' now supports the Jaguar's gpu. The VASM authors have been doing this for a long time and this assembler is probably way more advanced than any other Jaguar assembler. Although it won't be able to assemble both m68k and gpu code at the same time. You will need two different builds of the assembler for that.

 

You can find the sources here:

 

http://sun.hasenbraten.de/vasm/

 

As for whether or not its compatible with old Jaguar source code here is what one of the authors has to say about it...

 

Command line options are definitely different. But that's probably the
smallest problem for somebody who is interested.

The assembler syntax is more important, as I understand nobody wants to
rewrite his old sources. Here vasm is either compatible to Devpac (using
the "mot" syntax module) or optionally to the GNU-as (using the "std"
syntax module).

AFAICS Madmac is not compatible to Devpac. The functionality is similar,
but the Madmac directives start with a dot.

I am prepared [for feature suggestions and bug reports from the community]. The Atari ST scene already uses vasm a lot, because of the Devpac compatibilty.

Regards,

--
Frank Wille

 

 

So if the differences are small with madmac and devpak perhaps a tool to parse out the differences would solve the problem.

 

Or for someone just starting out who has no older source code they are attached to this might be a good thing.

 

VASM's complimentary Jaguar compatible linker is Vlink:

 

http://sun.hasenbraten.de/vlink/

 

So here that is if anyone wants to put that setup through it's paces on the Jaguar.

Edited February 22, 2015 by JagChris

[TXG/MNX]

Now VBCC with jagrisc support and everything is complete

[+CyranoJ]

It's great to see more tools. I probably will never use these, but it's still a good thing

 

 

Now VBCC with jagrisc support and everything is complete

 

It's always something else with some people. There's always *something* stopping them from doing anything, always a reason for them to keep hanging on asking for more and waiting. And when they get it, they find something else to pine for. Those projects that you think you can complete when you get everything? They won't ever be complete unless you actually start them. There's plenty of languages and tools out there 'complete' enough for projects to be made in languages other than assembler already.

 

Jump in and use what you have, rather than wait for the magic 'do everything' tool to land in your lap.

 

Nobody developing these tools and languages is ever going to implement something suggested by someone who always asks for more, yet never actually does anything. It's just not worth the effort.

Edited February 20, 2015 by CyranoJ

[LinkoVitch]

Frank Wille's assembler 'VASM' now supports the Jaguar's gpu. He has been doing this for a long time and his assembler is probably way more advanced than any other Jaguar assembler. Although it won't be able to assemble both m68k and gpu code at the same time. You will need two different builds of the assembler for that.

 

 

I don't understand...

 

"Way more advanced"

 

"won't be able to assemble both m68k and JRISC at the same time"

 

Those 2 things are pretty much mutually exclusive IMHO.

 

Can you explain how it is way more advanced? with examples of what it can do to make it more advanced? As requiring 2 separate builds makes it useless to me, the code I have has both JRISC and 68K included together. So it won't even match functionality that good ole MadMac supported.

 

As CJ said, great that there are more tools popping up all the time, but it's also better if they add something new or enhance already existing functionality.

[Shamus]

To pit a nit, this isn't Frank Wille's work, it's Dr. Volker Barthelmann's (http://www.compilers.de/vasm.html). That said, the only use case I can see for this is to use it as a back-end for VBCC when compiling C code for the Jaguar RISCs--which seems to be the Holy Grail of All Things Jaguar for some folks.

[JagChris]

Here is the 32bit Windows build of jagrisc VASM with the Motorola/Devpak syntax for anyone interested: vasmjagrisc_mot.zip

 

Here is the 32bit Windows build of Jagrisc VASM with the Standard/gasm syntax:vasmjagrisc_std.zip

 

32bit Windows VASM build with the new MadMac syntax module 0.2: http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=385306

 

and the latest 32bit Windows build of Vlink 15a vlink15a.zip

Edited June 1, 2015 by JagChris

[JagChris]

To pit a nit, this isn't Frank Wille's work, it's Dr. Volker Barthelmann's (http://www.compilers.de/vasm.html).

 

You're right. it seems VB does the core and Wille does most of the modules. Correction made in the thread title.

Edited February 22, 2015 by JagChris

[JagChris]

 

I don't understand...

 

"Way more advanced"

 

"won't be able to assemble both m68k and JRISC at the same time"

 

Those 2 things are pretty much mutually exclusive IMHO.

 

A lot of Jaguar development setups these days are already like that with two different assemblers creating object files for linking. Usually the 68k c compiler, whether it's gcc or vbcc has its own assembler making object files along with smac or madmac creating gpu object files. Then a linker, like vlink combining them all.

 

Vlink, Frank Wille's linker is pretty awesome. You can even use the latest windows/linux m68k elf gcc cross compiler and it will automatically convert all objects to jaguar a.out and link them for running in emulation. It will do this without a linker script or batting an eye. You can also do vice versa for skunkboard debugging with ELF. But a linker script is necessary for complete a.out to ELF conversion.

Edited February 22, 2015 by JagChris

[+CyranoJ]

 

A lot of Jaguar development setups these days are already like that with two different assemblers creating object files for linking.

 

Defn: A lot - none.

[JagChris]

I guess then whoever is and was using vbcc and Hillsofts SDKs to develop with like Dr Typo must have changed vbcc to point at smac instead of vasm for its object files. First I've heard of it.

 

No one has to use anything they don't want to.

[LinkoVitch]

A lot of dev setups?? where did all the dev's suddenly spring from?

 

Indeed, people should use whatever works for them, although making seemingly biased unfounded claims in favour of one particular solution over other is only going to get peoples backs up.

[GroovyBee]

I guess then whoever is and was using vbcc and Hillsofts SDKs to develop with like Dr Typo must have changed vbcc to point at smac instead of vasm for its object files. First I've heard of it.

Really? You haven't looked in the makefiles then have you? Dr Typo's Tube uses smac and even my own Duckie Egg uses smac (along with all my other jag projects). The hello world example in the HillSoft SDK even uses smac .

[JagChris]

Really? You haven't looked in the makefiles then have you? Dr Typo's Tube uses smac and even my own Duckie Egg uses smac (along with all my other jag projects). The hello world example in the HillSoft SDK even uses smac .

 

lol really? You guys are this flipped out over new development tools? I did not say they did not also use smac. I clearly stated they did also use smac.

Edited February 23, 2015 by JagChris

[sh3-rg]

No one has to use anything they don't want to.

 

See, that's not the way I heard it. I heard 2 months from now it's gonna be a bloodbath, no assemblers will survive, newspapers will refer to is as the assmblocalypse. Over night the Jaguar development community masses will become a one party nation - VASM or GTFO, yo.

 

 

lol really? You guys are this flipped out over new development tools? I did not say they did not also use smac. I clearly stated they did also use smac.

 

Seriously? You're doing a u-guise? GTFO, JagChris, and peep over the blinkered view from your cereal bowl. Maybe the issue is not the news but the messenger and the delivery.

 

Blablablubbablubbablobbyblobbysemblylubberinkiblinkyvasmjismwasmspazmcuntyasm.

[+CyranoJ]

VASM blows its brains out trying to assembler RAPTOR. If all those bugs can be sorted in a just a few months, plus multiple CPU targets integrated into a single pass... well.. then I still won't use it. It's very hard to trust a new assembler when you know its output is buggy. That's why I used MadMac for ages after SMAC came along, and only really switched once RMAC came into use and the bugs started to get worked out.

 

I know if I find a bug in RMAC it'll be picked up and fixed fairly quickly. With VASM, that could introduce months of delays. It's just not going to happen now that RMAC/RLN have had so many revisions and bug fixes.

[JagChris]

 

See, that's not the way I heard it. I heard 2 months from now it's gonna be a bloodbath, no assemblers will survive, newspapers will refer to is as the assmblocalypse. Over night the Jaguar development community masses will become a one party nation - VASM or GTFO, yo.

 

 

 

Seriously? You're doing a u-guise? GTFO, JagChris, and peep over the blinkered view from your cereal bowl. Maybe the issue is not the news but the messenger and the delivery.

 

Blablablubbablubbablobbyblobbysemblylubberinkiblinkyvasmjismwasmspazmcuntyasm.

 

 

Assemblyocopolypse? Well well we better get ready then!

 

Whatever issues you think you see with the messenger and the delivery you'll just have to live with it because I just don't care.

[JagChris]

VASM blows its brains out trying to assembler RAPTOR. If all those bugs can be sorted in a just a few months, plus multiple CPU targets integrated into a single pass... well.. then I still won't use it. It's very hard to trust a new assembler when you know its output is buggy. That's why I used MadMac for ages after SMAC came along, and only really switched once RMAC came into use and the bugs started to get worked out.

 

I know if I find a bug in RMAC it'll be picked up and fixed fairly quickly. With VASM, that could introduce months of delays. It's just not going to happen now that RMAC/RLN have had so many revisions and bug fixes.

 

 

Well you'll be safe then. Stick with Rmac or whatever.

[+CyranoJ]

 

 

Well you'll be safe then. Stick with Rmac or whatever.

 

I will, I just thought it was odd that 'the most advanced assembler out there' which will 'obsolete all others' dies trying to assemble nearly all of the existing Jaguar sources... Just saying...

[JagChris]

 

I will, I just thought it was odd that 'the most advanced assembler out there' which will 'obsolete all others' dies trying to assemble nearly all of the existing Jaguar sources... Just saying...

 

Of course it's not going to work. The author said it's not compatible with madmac syntax. And its a newly born baby risc backend. Of course there are going to be kinks. Once they start getting feedback I'm sure the authors will whip it into shape in no time.

 

It will obsolete them in my opinion only if a madmac syntax module is created. One doesn't exist yet.

[+CyranoJ]

It will obsolete them in my opinion only if a madmac syntax module is created. One doesn't exist yet.

 

Then why would you bother?

 

If it needs a syntax module to be madmac compatible, why not just use a madmac compatible assembler? That's just utterly pointless. And unless and until it can assemble 68000/JRISC in one file, in one pass it is pretty much a still-born baby. I think your opinion might just be a little bit opinionated here.

 

Seems like a lot of effort for no gain. Its not like there are lines of people queuing up waiting for it, either.

[JagChris]

 

Then why would you bother?

 

If it needs a syntax module to be madmac compatible, why not just use a madmac compatible assembler? That's just utterly pointless. And unless and until it can assemble 68000/JRISC in one file, in one pass it is pretty much a still-born baby. I think your opinion might just be a little bit opinionated here.

 

Seems like a lot of effort for no gain. Its not like there are lines of people queuing up waiting for it, either.

 

Then you don't need to worry about this 'still born baby'.

[+remowilliams]

I'm going to put this the nicest way I can - your enthusiasm is admirable, but your complete lack of even fundamental understanding in these things that you continue to attempt to discuss are several leagues beyond embarrassing.

[JagChris]

I'm going to put this the nicest way I can - your enthusiasm is admirable, but your complete lack of even fundamental understanding in these things that you continue to attempt to discuss are several leagues beyond embarrassing.

 

Good. Glad you enjoy them. More is coming.

[+CyranoJ]

 

Then you don't need to worry about this 'still born baby'.

 

I wasn't, don't worry about me on that front

 

I just don't get that something (lets call this something, just for example, 'VASM') that needs another non-existent something (lets call this 'MadMac Syntax Convertor') in order to emulate something else (aww hell, lets call this 'RMAC', eh?) will obsolete the something its pretending to be, when the non-existent something ('MadMac Syntax Convertor') will need to be updated every single time the something else ('RMAC', remember?) gets an update because it will need to be compatible with the thing it isn't.

 

That's like.. Never go full Jagtard.

Edited February 24, 2015 by CyranoJ

[JagChris]

 

I wasn't, don't worry about me on that front

 

I just don't get that something (lets call this something, just for example, 'VASM') that needs another non-existent something (lets call this 'MadMac Syntax Convertor') in order to emulate something else (aww hell, lets call this 'RMAC', eh?) will obsolete the something its pretending to be, when the non-existant something ('MadMac Syntax Convertor') will need to be updated every single time the something else ('RMAC', remember?) gets an update because it will need to be compatible with the thing it isn't.

 

That's like.. Never go full Jagtard.

 

Hmm... you sound worried.

 

Anyways when smac was being built I remember a few people asking for gasm compatibility. Now they have gasm and/or devpak compatibility if they want it. It's just another tool option.

 

If they don't then just let the stillborn baby rest in peace.