English Amiga Board


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

 
 
Thread Tools
Old 15 February 2015, 22:41   #21
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,040
Maybe an assembler like kick assembler could help too.
http://theweb.dk/KickAssembler/Main.php

Kamelito
kamelito is offline  
Old 15 February 2015, 22:52   #22
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 48
Posts: 1,838
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...
IFW is offline  
Old 16 February 2015, 19:10   #23
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,818
Quote:
Originally Posted by IFW View Post
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.
Photon is offline  
Old 17 February 2015, 21:36   #24
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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
Mrs Beanbag is offline  
Old 17 February 2015, 22:33   #25
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,818
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.
Photon is offline  
Old 11 March 2016, 12:26   #26
majikeyric
Registered User

majikeyric's Avatar
 
Join Date: Oct 2015
Location: France
Posts: 82
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.

Quote:
Originally Posted by Leffmann View Post
Eliminate annoying local labels and common errors in branch logic (vasm is probably the only assembler that can do this fully):
Code:
 macro if_equal
  bne  .\@!
 endm

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

 macro end_if
.\@@
 endm

Last edited by majikeyric; 11 March 2016 at 12:39.
majikeyric is offline  
Old 11 March 2016, 16:47   #27
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,569
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).
phx is offline  
Old 11 March 2016, 16:56   #28
Akira
Registered User

Akira's Avatar
 
Join Date: May 2001
Location: New York
Posts: 19,265
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.
Akira is offline  
Old 12 March 2016, 12:21   #29
majikeyric
Registered User

majikeyric's Avatar
 
Join Date: Oct 2015
Location: France
Posts: 82
Quote:
Originally Posted by phx View Post
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 ?)
majikeyric is offline  
Old 12 March 2016, 13:30   #30
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,569
Quote:
Originally Posted by majikeyric View Post
(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.
phx is offline  
Old 03 June 2016, 20:04   #31
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,088
Use macros for the math libraries because they're an enormous pain to use:
Code:
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:
Code:
    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.
Thorham is offline  
Old 15 July 2016, 15:10   #32
wk_end
 
Posts: n/a
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.
 
Old 16 July 2016, 17:21   #33
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
Quote:
Originally Posted by wk_end View Post
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.

Quote:
Originally Posted by Nekoniaow View Post
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.
Leffmann is offline  
Old 16 July 2016, 18:02   #34
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,088
Quote:
Originally Posted by wk_end View Post
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.
Thorham is offline  
Old 16 July 2016, 23:25   #35
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 630
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.
NorthWay is offline  
Old 16 July 2016, 23:30   #36
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 224
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
Kalms is online now  
Old 17 July 2016, 04:16   #37
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
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.
matthey is offline  
Old 17 July 2016, 08:26   #38
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by phx View Post
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.


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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.


Quote:
Originally Posted by matthey View Post
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'.


Quote:
Originally Posted by matthey View Post
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.
meynaf is offline  
Old 17 July 2016, 10:54   #39
modrobert
old bearded fool

modrobert's Avatar
 
Join Date: Jan 2010
Location: Bangkok
Age: 52
Posts: 525
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.
modrobert is offline  
Old 17 July 2016, 12:38   #40
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,088
Quote:
Originally Posted by matthey View Post
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.
Thorham 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
Neat idea - borderless WinUAE and Amiga wallpaper Bloodwych Amiga scene 8 13 January 2011 00:58
2000 - black screen... Chips good... PSU good... chiark support.Hardware 45 09 January 2009 06:41
Mitser Org'oeil, good platformer in old style s2325 Retrogaming General Discussion 2 23 November 2008 22:58
good retro racer in Lotus/Outrun style s2325 Retrogaming General Discussion 4 27 May 2007 21:57
very good new racing PC game in old style s2325 Retrogaming General Discussion 1 20 February 2007 23:34

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 00:35.


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