64-bit ARM assembler

[Deleted User 9295]

By the way, Richard, your code is really nice to work with!

You're lucky to be working with a module that was written from scratch. The great majority of the C code of BBC BASIC for SDL 2.0 was created more-or-less 'mechanically' from the assembly language source code of BBC BASIC for Windows and it's anything but 'nice', it's really messy with meaningless variable names like esi or ebp reflecting the register used to hold that value in the assembler code.

I had more-or-less assumed that the naïve approach I'd adopted for the 32-bit ARM assembler wouldn't be appropriate for the 64-bit version, and that one would need to move to a table-driven method similar to what is used for the x86 assemblers. Do I gather that you are continuing to use much the same approach as the 32-bit assembler? Do you feel that would be extendable if one wanted to support floating-point and/or vector (SIMD) instructions in the future?

[Stoppers]

Do you feel that would be extendable if one wanted to support floating-point and/or vector (SIMD) instructions in the future?

Yes, I think so, although I've not been interested in floating point code, generally.

The job of the assembler seems to be to find the appropriate encoding for a given mnemonic (MOV, for example is an alias of multiple different instructions, depending on what's being moved). I don't see why any instruction should be a major problem.

By the way, one change I did make was to search through the alphabetically sorted mnemonics from last to first; MOV matched MOVK, first. Suffixes are rare in Aarch64.

[Stoppers]

Some interesting related links to the bitmaps (N immr imms):
https://stackoverflow.com/questions/309 ... 5#33265035
https://dinfuehr.github.io/blog/encodin ... n-aarch64/
https://gist.github.com/dinfuehr/51a01a ... 313ed6a06a

[Deleted User 9295]

Some interesting related links to the bitmaps bitmasks (N immr imms)

If it helps, I'd be happy for the assembler to report an error if the specified immediate constant isn't one of the 5334 possible values that can be encoded in a single instruction. I wouldn't expect it to choose an alternative multi-instruction encoding scheme for other values, unless you particularly want to attempt that.

[Stoppers]

Some interesting related links to the bitmaps bitmasks (N immr imms)

If it helps, I'd be happy for the assembler to report an error if the specified immediate constant isn't one of the 5334 possible values that can be encoded in a single instruction. I wouldn't expect it to choose an alternative multi-instruction encoding scheme for other values, unless you particularly want to attempt that.

That was all I was planning on! Just the identification of valid values and their encoding as bitmasks (thanks!) is a complex enough problem.

[Stoppers]

Here's the plan:
Rotate left until the lsb is 1 and the msb is 0
Count the number of 1 bits at the least significant end
Count the number of 0 bits above those
The sum of those two counts is the pattern size
The pattern size must be a multiple of 2
Generate the pattern the processor should produce
Check the immediate value against the pattern generated
Build the appropriate values for N:immr:imms

It seems to work.

[Deleted User 9295]

It seems to work.

Excellent.

Just a thought, but would it be a good idea for you (and perhaps Jonathan) to add a comment to the relevant Issue thread at GitHub, just to be sure that anybody else who might be working on an assembler knows about your work, and so duplication of effort can be avoided.

[jgharston]

Here's the plan:
Rotate left until the lsb is 1 and the msb is 0
Count the number of 1 bits at the least significant end
Count the number of 0 bits above those
The sum of those two counts is the pattern size
The pattern size must be a multiple of 2
Generate the pattern the processor should produce
Check the immediate value against the pattern generated
Build the appropriate values for N:immr:imms

It seems to work.

Is that for logical instructions? I'd been scratching my head on that one. Arithmetic instructions is the "normal" ARM32 encoding, k*2^(2*r).

[Deleted User 9295]

Is that for logical instructions? I'd been scratching my head on that one.

Yes. AArch64 uses an entirely different algorithm for encoding logical immediate operands compared with arithmetic immediate operands. The thinking seems to be that the most likely wanted values are quite different (for example -1 is a likely arithmetic immediate, but a very unlikely logical immediate). It seems to be a lot of trouble to go to, but I suppose in silicon it doesn't amount to much.

[Stoppers]

Is that for logical instructions? I'd been scratching my head on that one. Arithmetic instructions is the "normal" ARM32 encoding, k*2^(2*r).

There's a good description, here:
https://dinfuehr.github.io/blog/encodin ... n-aarch64/

By the way, is there a way I can get full 64-bit values from an expression? I can't test the numbers to go into a 64-bit register. I found this, in bbeval.c:

Code: Select all

2070				if ((liston & BIT2) == 0)
2071					v.i.n = (v.i.n << 32) >> 32 ;

Can I, should I, set that bit somehow, to get full sized values? If so, how?

[Stoppers]

I finally get the point of the extend modes; they extend the value in a register from a byte, half-word or word to a full 64-bit value, signed or unsigned.

[Deleted User 9295]

By the way, is there a way I can get full 64-bit values from an expression?

Integer numeric expressions do return 64-bit values: v.i.n is declared as being type long long (extract from BBC.h):

Code: Select all

typedef union tagVAR
{
        long double f ;
        struct
        {
          long long n ;
          short t ; // = 0
        } i ;

You can always refer to the code of the 64-bit x86 assembler bbasmb_x86_64.c if you need any examples of handling 64-bit operands.