11 March 2016 - Forum Rules

Main Menu

Bass Assembler

Started by jvplouvem, August 24, 2021, 10:48:53 AM

Previous topic - Next topic


Hey guys,
I would like to know if the bass assembler ( has a command equivalent to cc65's .LOWORD (

If not, is there any other way to do this procedure?



I am not sure I have really seen anybody use bass as their assembler when playing in the ARM9 world (though I have not been paying too much attention to the 3ds stuff so maybe it got popular there), and a casual scan of its does not reveal much in the way of pseudo functions comparable to the list of those on the second link, though you could probably define one for it. I am not even sure it has the classic pseudo function of most ARM assemblers where you can write a full 32 bit immediate and have it handle it (though I did not look properly).
Most instead tend to go for a cut down version of arm-eabi (I have a really old version from an old trainer making setup, though devkitpro/devkitarm is probably where most would go today, however is not without its charms), armips , no$gba's stuff or have something fancy going on with IDA, ARM-SDT or possibly ghidra ( ).

"The function returns the low word (that is, bits 0-15) of its argument."
I am not entirely sure what that is heading for
Generally you have two approaches most would look at
1) Fun with shifting, and ARM has notably good shifting options (see barrel shifting if you are bored and care). shift it 16 bits one way, shift it back and what was the upper bits should now be zeroed out. Not sure offhand how many cycles it might take (lots of bits being shifted can make things take longer at times) so might be slower than you like.
2) Fun with Boolean logic. Easy enough to do AND or NAND with everything in the section you don't want set to 0 and everything else set to 1 such that the Boolean stuff does it for you. Might be quicker, this sort of approach is also popular with the modern X86 optimisation crowd where filtering is used to minimise code branching (which is slow as branch prediction is a major part of things.
Wrap that in a bit of push and pop to ensure you have registers to play with. Rather than mov do make sure to look up movn (mov negate/negative, basically take what you want and invert it -- if you wanted all the upper bits to be 1 then setting all the lower bits to 1 which should be within the possibilities of the immediate limits in basic ARM) has the boolean options, could probably even do some more than what I suggested.


Thank you very much for clarifying these details.

I'm using this assembler because I'm following a friend's video series on youtube and as he uses Bass, so I decided to use it too to learn better and get support.

I really liked the cc65, maybe I'll come back to it the day I learn how the SNES works well. which is far away for the time being (LOL)

Thank you so much, friend !


@Fast6191 : Why are you talking about ARM ? ARM9 is the nickname of the maintainer  :).
bass doesn't support ARM assembly, armips is better for this.


That is called not paying attention... no wonder I had never seen it used for fiddling binaries that are destined for ARM devices.

Oh well. I will stand by the earlier remark of it not featuring the pseudo instructions/assembler provided functions of the second link, though it does appear extensible enough by its very nature that you could probably create them happily enough. Blanking bits out on most things* is still going to be Boolean or shifting though, shifting tending to be for one or two bits to be lost (say someone uses the high bit as an indicator of something as you don't technically need the full range otherwise -- 32 bits is about 4 gigs after all, few files anybody doing any ROM hacking with ending up that big) but often able to be done with fewer registers where boolean is almost certainly going to need multiple registers for things and handling either patterns of things that shifting would struggle with or larger sections needing blanking if it is a system where shifting large amounts of data a lot of places (and back again) is slow.

*X86 being a major exception as it has the whole nested registers thing.


arg & 0xffff
evaluates to the low 16 bits of arg.