vasm with Apollo Core 68080 and AMMX support

[phx]

Todays vasm snapshot
http://sun.hasenbraten.de/vasm/daily/vasm.tar.gz
is the first assembler to support Apollo 68080 and its AMMX extensions, after merging all the new Apollo Core support code into the main trunk. This has been a work of continuous modifications and testing over the last three months, while the ISA was still evolving. The Apollo team told me that the ISA is pretty stable now, and I hope there will be only minor changes and bug fixes until the official 1.8 release.

Feel free to test and report any problems with it. Refer to the documentation for how to enable 68080 mode.

The standard 68k assembler should still work as before. It was my main concern that Apollo does not degrade the performance of the 68k assembler backend in any way.

[grond]

Thank you very much!

Kreuzberger Nächte sind lang!

[Nickman1200]

Wow nice and good job.

[buggs]

Many thanks Frank. You've provided tremendous help with the implementation of the 68080 ISA extensions in VASM.

Also, with the excellent groundwork you've laid out, I'm sure that I'll be sending way more patches than requests in the future (i.e. should the need for further additions arise).

[flype]

Lot's of kudos Phx for all the efforts puts in this update, much appreciated.

[wawa]

Originally Posted by grond

Thank you very much!

Kreuzberger Nächte sind lang!

hattest du kein blackout? bei mir ist gerede eben erst licht angegangen.

@phx

not that i am a fan of another platform split, but as long as its asm, which means mostly dedicated drivers or punctually optimized inlines i say: bravo!

[TuKo]

Many thanks! vasm is now de facto my main asm compiler

[buggs]

Originally Posted by wawa

hattest du kein blackout? bei mir ist gerede eben erst licht angegangen.
@phx
not that i am a fan of another platform split, but as long as its asm, which means mostly dedicated drivers or punctually optimized inlines i say: bravo!

Aren't we all used to the "pick one" concept when it comes to distributed binaries of programs and associated libraries? One more build variant doesn't change much, IMHO.

Most of the guys still actively coding for the Amiga have more than one machine and ample motivation to deploy their own stuff on all of them.

Also, even when targeting ISA extensions with some of the code, the generic 68k compatibility codepath comes in quite handy when writing/testing the one or other codeblock by help of UAE or VAMOS.

[wawa]

Originally Posted by buggs

Most of the guys still actively coding for the Amiga have more than one machine and ample motivation to deploy their own stuff on all of them.

first of all, im not kinda nitpicking. the problem are not the developers. the problem are the noob users. the forums are full of them and if you want to attract anyone beyond that, you will face some challenge explaining them the art of version hell of binaries compiled for a paricular cpu, as is it was unfortunatelly the (uncanny) custom with amiga software in the nineties.

im not trying to break off another useless discussion like in riva thread, but id prefer to see people encouraged for a responsible practice with the available functionality. i think this would be trying to restrict that ammx asm to a critical libraries or inlines, where it makes a difference, rather getting it spilled all around newly producd code, leading to unnecessary problem reports. of course it remains up to the users, but the team could lead the way.

thus speaking as apollo supporter, while staying with my genuine machines for the time being.

[buggs]

Originally Posted by wawa

first of all, im not kinda nitpicking. the problem are not the developers. the problem are the noob users. the forums are full of them and if you want to attract anyone beyond that, you will face some challenge explaining them the art of version hell of binaries compiled for a paricular cpu, as is it was unfortunatelly the (uncanny) custom with amiga software in the nineties.

im not trying to break off another useless discussion like in riva thread, but id prefer to see people encouraged for a responsible practice with the available functionality. i think this would be trying to restrict that ammx asm to a critical libraries or inlines, where it makes a difference, rather getting it spilled all around newly producd code, leading to unnecessary problem reports. of course it remains up to the users, but the team could lead the way.

thus speaking as apollo supporter, while staying with my genuine machines for the time being.

Wawa, my threat detector might have been off balance recently but I tend to think that I'm capable of learning. Besides, I see a clear pattern in your posts as a voice of reason.

I'm actually experimenting in different directions when it comes to the usage of extended ISA features. Sometimes it is of advantage having a flexible codebase you can deploy everywhere. I did write some improved blitting functions for SDL recently, for which the library decides on the proper code paths for the current architecture. But it is as you said, this approach works well and with low overhead for ASM subroutines.

As soon as decisions get bigger (FPU/NoFPU/000/020 etc), other questions come into play. Amigas are heavily resource constrained in all directions: Storage in terms of capacity and speed, RAM, CPU. In this light, the installation of targeted versions of given software make sense from a technical POV.

Of course, I cannot forsee the future and neither can speak of how other ppl will act. But I for sure have recapped my A4k for a reason.

[wawa]

Originally Posted by buggs

for which the library decides on the proper code paths for the current architecture

yes something of that sort. im aware there are pros and contras.. but for a disk based library some additional conditional asm inlines in one file shouldnt be that much of balast. similar with an player coded fully in asm. on the other hand it is more challenging for the coder, but it might pay off.

another example here is netsurf, where several versions with different guis, and then for aga or rtg are hovering around, and i see people getting dizzy with this..

okay. had may say, i wish you good progress

[kolla]

Any software with dedicated 68080 support could very well support 68000-68060 within the same binary too, and the confusion could be avoided.