Neat coding style and good habits

[kamelito]

Maybe an assembler like kick assembler could help too.
http://theweb.dk/KickAssembler/Main.php

Kamelito

[IFW]

DevPac(genam)+SAS/C linker all the way
Obviously, these days it would be completely different - I am not crazy enough anymore to make RPGs in assembly or even pure C...

[Photon]

Originally Posted by IFW

Actually with the amount of assets we had for our games, converting IFF images on the fly would have been a nightmare, and completely unfeasible due to the extra number of disks required plus the extra amount of memory the game would have needed for buffering. Some of the assets were hundreds of KBs animated IFFs, so just recycling one of the off-screen buffers while clipping and converting the image would not have been possible without asking for a minimum of 1.5MB memory instead of 1MB.

IFF is just RLE, no need for buffering. It's certainly convenient and loads quickly. Yours sounds like a special project. I was referring to the much more common task of adding bobs and other gameplay graphics content to a game or game part.

[Mrs Beanbag]

btw if anyone has good code for loading IFF images i'd be very grateful... currently i am still having to use AMOS to do all my file conversion work

[Photon]

Have you checked coppershade...? Must be tons out there, though. #IFF.S Won't load anims but won't choke on stencils, IIRC. Made it a long time ago.

[majikeyric]

Great topic!

Where can I find information about the syntax of the labels used in these macros ? I didn't find in VASM documentation.

I would want to know if it is possible to create other ASM macros to define : do-while, while, switch... structures.

Originally Posted by Leffmann

Eliminate annoying local labels and common errors in branch logic (vasm is probably the only assembler that can do this fully):

 macro if_equal
  bne  .\@!
 endm

 macro else_if
  bra  .\@?
.\@@
 endm

 macro end_if
.\@@
 endm

[phx]

Those are special Leffmann additions.

I remember that he suggested them for implementation into vasm, but they were obviously never documented. All are variants of \@ (replaced by a unique id for this macro call). They make it possible to refer to unique ids of a previous macro call.

\@! means: push the current unique id onto a global stack, then insert it.

\@? means: push the current unique id below the top element on this global stack, then insert it.

\@@ means: pull the top element from the global id stack and insert it (but do not replace the current unique id for further usage).

[Amiga1992]

Yes please comment all the things and be as verbose as possible, especially if you intend too SHARE the code with other people. I am a learner and many times I have a hard time following code because of lack of comments, or very tiny comments that assume things/prior knowledge.

[majikeyric]

Originally Posted by phx

Those are special Leffmann additions.
\@! means: push the current unique id onto a global stack, then insert it.

\@? means: push the current unique id below the top element on this global stack, then insert it.

\@@ means: pull the top element from the global id stack and insert it (but do not replace the current unique id for further usage).

wow great additions! Thanks for that phx !

All kind of control structures should be doable then!

(why not document them ?)

[phx]

Originally Posted by majikeyric

(why not document them ?)

It was forgotten. Did that now. And I have also put all special macro parameters into a table to make it more readable.

[Thorham]

Use macros for the math libraries because they're an enormous pain to use:

selectMathBase set 0

setMathBase macro
    ifle selectMathBase
selectMathBase set 1
    move.l  mathBase,a6
    endc
 endm

setMathtransBase macro
    ifge selectMathBase
selectMathBase set -1
    move.l  mathtransBase,a6
    endc
 endm

spflt macro
    setMathBase
    move.l  \1,d0
    jsr     _LVOSPFlt(a6)
    move.l  d0,\2
 endm

spdiv macro
    setMathBase
    move.l  \1,d0
    move.l  \2,d1
    jsr     _LVOSPDiv(a6)
    move.l  d0,\3
 endm

sppow macro
    setMathtransBase
    move.l  \1,d0
    move.l  \2,d1
    jsr     _LVOSPPow(a6)
    move.l  d0,\3
 endm

Now you can just write:

    spfix   #123,d2 ; set d2 to 123
    spdiv   d2,d3,d2 ; divide d2 by d3, store result in d2
    sppow   d2,d3,d2 ; raise d2 to d3, store result in d2

The macros set the correct library base when necessary. Just don't use d0 and d1 as parameters.

Does anyone have any thoughts on a good way to deal with calling conventions and locals? I've been trying to follow the convention used by the ROM libraries (d0-d1/a0-a1 are temporary, everything else is callee-preserved) and I'm finding I'm spending a lot of code on pushing/popping things from the stack or shuffling data in and out of the callee-preserved registers.

[Leffmann]

Originally Posted by wk_end

Does anyone have any thoughts on a good way to deal with calling conventions and locals? I've been trying to follow the convention used by the ROM libraries (d0-d1/a0-a1 are temporary, everything else is callee-preserved) and I'm finding I'm spending a lot of code on pushing/popping things from the stack or shuffling data in and out of the callee-preserved registers.

This is really inherent to machine language programming, and I think the best solution is to write most stuff in C, and only use machine language for the few parts that need to be small and fast.

If size and performance doesn't matter, or if you're writing machine language just because you prefer it, then one compromise would be to keep all local variables on the stack as you work with them, since most arithmetic and logic operations can be done on memory operands. Using macros to emulate high-level language function calls and hiding the pushing/popping of variables could be useful as well.

Originally Posted by Nekoniaow

This is more a general remark than an assembler specific one but one should always use source control.
With something like Git (or Perforce, which is free for personal non commercial use) you should push every single version of your code which compiles. This is a tremendous help when you need to figure out what exactly is it that you changed which broke your program about ten compilations before or just want to revert to a working, validated version

I've started doing exactly this when using makefiles.

When the main target builds without errors, it will automatically do a commit with a blank message, and when I'm happy with the changes I'll amend a proper commit message, and finally I go back and squash the blank commits before and if I push to a remote repo.

[Thorham]

Originally Posted by wk_end

Does anyone have any thoughts on a good way to deal with calling conventions and locals? I've been trying to follow the convention used by the ROM libraries (d0-d1/a0-a1 are temporary, everything else is callee-preserved) and I'm finding I'm spending a lot of code on pushing/popping things from the stack or shuffling data in and out of the callee-preserved registers.

You only need to follow the OS calling conventions when calling OS functions. Do what's most convenient in parts of your code where there are no OS calls.

As for locals, keep them in registers when writing speed critical routines whenever possible, otherwise use what's most convenient and yields the cleanest code.

[NorthWay]

ISTR some _real_ old BIX thread printed in BYTE with Jez San discussing calling conventions and him having landed on the side of all saves being done callee side?
Bah, this wasn't worth much without an exact quote, but if someone can find and look through old BYTEs with their "Best of BIX"(?) I think you should find it.

[Kalms]

Practically all compilers' calling conventions are a combination of caller-saved and caller-saved. This in itself is a good indication that a mixed approach gives the best performance/code size tradeoff.

Sent from my D5503 using Tapatalk

[matthey]

Maybe we can guess at the history from the beginning.

1) stack args were caller deallocated
2) instructions like 68k RTD (Return and Deallocate) and x86 RET with immediate made callee deallocate faster
3) inefficient but convenient variable args became more popular making RTD type instructions unusable for those functions
4) high end processors received enough registers to pass args in registers and ABIs changed to suite (reg args have no deallocation although the caller may need to store data in scratch regs before calling and the callee needs to save any preserved regs)

The 68k of course still uses the ancient AT&T ABI which is the least efficient possible despite having enough registers to use for reg args (the AmigaOS uses reg args for libraries but compilers still pass args on the stack by default). The ColdFire didn't update the ABI but they added the MOV3Q instruction which is very useful for moving small immediates to the stack (MOV3Q would not have been worth adding if they changed to a reg arg ABI). Most assembler programmers would probably have not noticed and didn't seem to care about the ugly MOV3Q instruction and the kludge for a kludge. Add it to the list of 68k CPU design screw ups.

1) 68040 removed the FINT/FINTRZ instruction which is common for C fp conversions
2) 68060 removed the MULS.L/MULU.L (64 bit result) instructions which was used by GCC for DivMagic with a large cycle savings
3) ColdFire removed 68k encoding compatibility and added many ugly bolt-on instructions which didn't match with the 68k naming conventions but kept the inefficient ABI and even added instructions to support it
4) Apollo core's naming conventions are just as ugly with BSEL (B=Byte where 68k first B=Bit) and MOVEX (X=cross rev? where 68k end X=X CCR bit)

I guess assembler programmers don't care about ugly and poorly designed APIs/ABIs though. I guess they don't plan on using or supporting enhancements. I seem to be the only one who used to care. I just hope nobody expects me to add support in a compiler for this crap (I wanted to make it easier for compilers to generate good code). Maybe it is time to let the 68k rest in peace. That seems to be what most of the 68k retro "real" hardware guys want anyway. Let the 68k CPU die with them while the younger kids will never know a CPU was so easy to program.

[meynaf]

Originally Posted by phx

I remember that he suggested them for implementation into vasm, but they were obviously never documented. All are variants of \@ (replaced by a unique id for this macro call). They make it possible to refer to unique ids of a previous macro call.

I'd like to see an example where this is useful. Beware of macro abuse, it can easily lead to totally unreadable code. Okay, you know your own macros. But other people reading your code don't.

Originally Posted by Thorham

You only need to follow the OS calling conventions when calling OS functions. Do what's most convenient in parts of your code where there are no OS calls.

Or better, encapsulate the OS calls completely.

Originally Posted by matthey

3) inefficient but convenient variable args became more popular making RTD type instructions unusable for those functions

Not a big deal, as varargs aren't very common. Nearly only printf-like stuff use it.

Originally Posted by matthey

The 68k of course still uses the ancient AT&T ABI which is the least efficient possible despite having enough registers to use for reg args (the AmigaOS uses reg args for libraries but compilers still pass args on the stack by default).

Whose the fault ? Poor 68k isn't responsible of compilers doing stupid things. In fact the greatest handicap of 68k compared to other cpus (in the ancient times where it was still mainstream), was poor compiler generated code.

Originally Posted by matthey

The ColdFire didn't update the ABI but they added the MOV3Q instruction which is very useful for moving small immediates to the stack (MOV3Q would not have been worth adding if they changed to a reg arg ABI).

I wouldn't regard MOV3Q as useful, even for that case. What's the win ? 2 bytes every time you push a small value. Big deal.

Originally Posted by matthey

Most assembler programmers would probably have not noticed and didn't seem to care about the ugly MOV3Q instruction and the kludge for a kludge. Add it to the list of 68k CPU design screw ups.

There are indeed better uses for line-a encoding space.

Originally Posted by matthey

2) 68060 removed the MULS.L/MULU.L (64 bit result) instructions which was used by GCC for DivMagic with a large cycle savings

64-bit MUL&DIV are very, very useful. I use them all the time.
Removing them from 060 was a really poor move.

Originally Posted by matthey

3) ColdFire removed 68k encoding compatibility and added many ugly bolt-on instructions which didn't match with the 68k naming conventions but kept the inefficient ABI and even added instructions to support it

True. Some additions are neat, though. MVZ, MVS, BITREV, BYTEREV are quite missing in classical 68k.

Originally Posted by matthey

4) Apollo core's naming conventions are just as ugly with BSEL (B=Byte where 68k first B=Bit) and MOVEX (X=cross rev? where 68k end X=X CCR bit)

Ugly names for useless instructions. No big deal

Originally Posted by matthey

I guess assembler programmers don't care about ugly and poorly designed APIs/ABIs though.

It seems not many people care at all.
But good programming starts with a good architecture.

Originally Posted by matthey

I guess they don't plan on using or supporting enhancements. I seem to be the only one who used to care.

I would be using enhancements, if new stuff could deserve that name.

Originally Posted by matthey

I just hope nobody expects me to add support in a compiler for this crap (I wanted to make it easier for compilers to generate good code).

Just say 'no'.

Originally Posted by matthey

Maybe it is time to let the 68k rest in peace. That seems to be what most of the 68k retro "real" hardware guys want anyway. Let the 68k CPU die with them while the younger kids will never know a CPU was so easy to program.

Perhaps the 68k needs some kind of worthy successor, which unfortunately isn't gonna happen either.

[modrobert]

Lots of interesting tips here for a slowly progressing 68k apprentice like me, thanks.

matthey,

Please drop the doom and gloom attitude, cheer up, take a good look at this:

https://www.google.com/trends/explore#q=Amiga

Sure, the "Amiga" trend is somewhat affected by the Spanish use of the word, but that's part of the charm, and one of the reasons it was chosen. I guess as long as girlfriends are trending, there is hope for our beloved computer platform.

[Thorham]

Originally Posted by matthey

Maybe it is time to let the 68k rest in peace. That seems to be what most of the 68k retro "real" hardware guys want anyway. Let the 68k CPU die with them while the younger kids will never know a CPU was so easy to program.

That's certainly not what I want. I want REAL 68k with REAL Amiga chipset, not an FPGA computer with Amiga stickers on it.