View Amos generated assembly code?

[Brick Nash]

This is a long shot, but does anyone know if there's a way to look at the generated assembly code that Amos produces? I've looked the through the menus and extensions, but I can't see any way of doing it.

I'm trying to learn Amiga ASM at the moment, and it'd be great if I could just set something up in Amos and then look at what the assembly code was doing. I'm fairly familiar with what Amos can do, so to be able to translate and compare would be a real boon!

If not then no problem. Just thought I'd ask as it seemed like a good idea.

(Apologies if this is in the wrong section, but it does concern Amos)

[hooverphonique]

use a machine code monitor program or similar - it will show you the assembly in the generated executable..

[saimo]

Compile the code without including amos.library and disassemble it. To easily find where the piece of code you're interested in actually starts, write something like this:

A=$12345678
<your code>

Then search for $12345678 in the disassembled code.

That said, this method won't help you learn - and actually might well give you bad ideas - because the compiled AMOS code is not efficient and is full of jumps to amos.library routines.


Edit: here's a quick example.

Let's consider this simple piece of AMOS code:

A=$12345678
Add A,1

Of course, it's stupid to begin with: one could simply assign $12345679 to A; however, the point here is to show how even the simplest code is compiled inefficiently by the AMOS Compiler.
This is the generated assembly code:

   MOVE.L    #$12345678,D3
   MOVE.L    D3,2(A6)
   MOVEQ.L   #1,D3
   ADD.L     D3,2(A6)

Such code does the following:
1. puts the value $12345678 in the data register d3;
2. stores the content of d3 into the memory location pointed by the value stored in the address register a6 plus 2 (such memory location is evidently the memory space assigned to the variable A);
3. puts the value 1 in the data register d3;
4. adds the value of the data register d3 to the value stored in the memory space of the variable A.

A much better translation - and still 1:1, without any human-conceived trickery - would have been:

   move.l   #$12345678,2(a6)
   addq.l   #1,2(a6)

An optimizing compiler might come up with:

   move.l   #$12345678,d3
   addq.l   #1,d3
   move.l   d3,2(a6)

This is much better because there is only 1 access to memory (the final write) instead of the 3 accesses (the initial write, the read from memory performed by add to fetch the variable value and the final write performed by add again) of the other examples above.

A good optimizing compiler would instead write the optimal code:

	move.l	#$12345679,2(a6)

Final note: A was the only variable on the program; it's likely that it occupies the first slot in the variables buffer; it's also likely that the variables buffer is longword-aligned (thanks to how the AmigaOS memory allocation routines work); therefore, it seems that 2(a6) is a word-aligned address: it if were so, the longword accesses actually require twice the accesses, thus causing a noticeable performance hit. That said, I don't know how AMOS handles the variables, so I'm hoping that 2(a6) is actually longword-aligned.

[Brick Nash]

Thanks for the replies folks!

@saimo I'm not too fussed about the code being super optimised. It's just to get a general overview of what's happening/how it's happening, which I think would be enough. I've seen other examples which aren't optimised, but have still helped me a lot because they're specific to a task. For other tasks I can't seem to find any examples at all, so I thought this would be a nice compromise.

Either way, that's some great info you've provided, so I'll give that a try. I'd only be doing very simple things anyway, but as I say, it's just to get an idea.

Thanks!

[fxgogo]

So I am not an assembler programmer at all, but on the cusp of wanting to learn it myself. This resource below has quite a few books from back in the day on the subject:

https://commodore.bombjack.org/books...ming_Guide.zip

[saimo]

Originally Posted by Brick Nash

I'm not too fussed about the code being super optimised. It's just to get a general overview of what's happening/how it's happening, which I think would be enough. I've seen other examples which aren't optimised, but have still helped me a lot because they're specific to a task. For other tasks I can't seem to find any examples at all, so I thought this would be a nice compromise.

It isn't just a matter of optimization: for example, the AMOS code I showed might lead the reader to think that the M68k has a load/store architecture - which, of course, isn't the case.

Either way, that's some great info you've provided, so I'll give that a try. I'd only be doing very simple things anyway, but as I say, it's just to get an idea.

Thanks!

You're welcome, and feel free to go about it the way you prefer. If I may, I'd suggest you get hold of some specific book that teaches assembly programming and also the M68000 Family Programmer's Reference Manual.

[Brick Nash]

@fxgogo Thanks for the link! I've downloaded.

@saimo Thanks for the reference, I don't think I have that book, though I do have the HRM.

I've got a little "sort of" game demo working in assembly language (in that I can move an image around the screen with a gamepad with some screen boundaries etc.), but it was just to try and gather code references for things I can't really find any examples for (H-Flipping, Split screens, etc.). These things are so easy to do in Amos, so I thought it may be a good resource if I could see the ASM.

[redblade]

Thanks for the info saimo.

Now I wonder how AmigaBasic by Micro$oft worked.