I apologize for this mess. One of the blessings (?) of old age is deteriorating vision. I am having increasing problems with reading that the ophthalmologist has been unable solve with different glasses.
I sympathise, I may not be very old but in the past five or ten years I've developed some problems with my vision in my left eye that are not showstoppers but are increasingly annoying, I can no longer glance at things and read them instantly, most things need at least a second look or a long stare. I'm conscious it's only going to get worse from here!
Quote:
The XOR operation in the Kowalski assembler operates on 32 bits. It can’t be directly used as gfoot illustrated. Something such as <{~15} might work, but I haven’t tried it.
I would have expected it to still work as the result of the "and" operation will still be as short as the input value was. The idea is just to mask the input value to only keep its high bits, so that we round down to a multiple of 16. You could use "& -16" instead possibly, or "& {65535-15}" if you want it 16-bit and need to only use 16-bit constants in the expression, it's a bit less tidy though. Still it won't matter much when you wrap it in a macro.
I sympathise, I may not be very old but in the past five or ten years I've developed some problems with my vision in my left eye that are not showstoppers but are increasingly annoying, I can no longer glance at things and read them instantly, most things need at least a second look or a long stare. I'm conscious it's only going to get worse from here!
I entered the realm of the octogenarian this year, but my vision problems started about 18 years ago when I developed immune thrombocytopenia and was undergoing weekly chemo. The drugs with which I was being treated were determined to have contributed to the formation of a macular cyst in my left eye. An attempt at breaking down the cyst was unsuccessful. At this point in time, my left eye is mostly along for the ride.
Quote:
Quote:
The XOR operation in the Kowalski assembler operates on 32 bits. It can’t be directly used as gfoot illustrated. Something such as <{~15} might work, but I haven’t tried it.
I would have expected it to still work as the result of the "and" operation will still be as short as the input value was.
At some point, I’ll give it a try.
Quote:
Still it won't matter much when you wrap it in a macro.
Yep! All else fails, bury it in a macro.
Incidentally, I settled on “paragraph” to describe the 16-byte whachamacallit.
What you're doing is aligning the address. Eg, ALIGN 2 aligns to an even address, you're doing ALIGN 16 to align to an address that is a multiple of 16.
So, I'd recommend defining a macro called ALIGN and just putting ALIGN 16 ; Align to next slot in your code.
What you're doing is aligning the address. Eg, ALIGN 2 aligns to an even address, you're doing ALIGN 16 to align to an address that is a multiple of 16.
So, I'd recommend defining a macro called ALIGN and just putting ALIGN 16 ; Align to next slot in your code.
I have several macros that do “align” things, with names such as dwalign (double-word align, aligns up to an address that is a multiple of 4), pagalign (aligns up to an address that is a a multiple of 256), etc.. The macro that aligns up to the nearest multiple of 16 is called paralign (paragraph align).
Most of my code is peppered with macros, more as a defensive programming measure than anything else. Defensive programming especially became a concern when I first started writing for the 65C816 and making heavy use of the stack for parameter passing. It is much too easy to get a stack frame out of order and have all sorts of bizarre things happen. Using macros to make function calls helps to catch that class of errors. Macros also simplify passing different pointer types (“near”, “far”, etc.) into a function.
I have an entire file full of macros that gets INCLUDEd into all but the simplest programs.
