Editor Ahoy

What it the best way forward – with regards 64bit file editor?

Modifing ‘Edit’ to take Zap/StrongEd modules?

Or perhaps Zap/StrongEd be made to display 64bit files.

A 64bit debugger module?

Can you be more specific what 64bit files you’re referring to? From your mention of Debugger I assume you’re talking about 64bit binary files.

Both Zap/StrongED 4.70a12 can already display binary files as a doubleword hexdump. Is that what you’re after or do you need something else?

What it the best way forward – with regards 64bit file editor?

A 64 bit OS to ruin it on?

Edit: “ruin”, another example of pathetic autocorrect, but it made me giggle so I’ve left it.

Rick – made me smile :-)

Will we have to come to terms with a 64 bit OS?

Fred-
It would be interesting to see what the 64 bit code looks like.

Perhaps there are 64bit ARM examples – in text.

Examples? Google found this: https://github.com/matja/asm-examples/blob/master/aarch64/taylor-sin.aarch64.linux.libc.gas.asm

It’s sort of vaguely ARM-like and…

It would be interesting to see what the 64 bit code looks like.

Both Zap and StrongED use the Debugger module to disassemble ARM code so for them to display 64bit code the Debugger module would have to gain support for such code.

Of course that would be in plain uncoloured text, the real fun would be to add syntax highlighting for 64bit code.

the real fun would be to add syntax highlighting for 64bit code.

The layout looks a lot like traditional ARM. It may suffice to just teach it the new register names? And that numbers don’t need a # prefix, but this may be specific to that assembler…?

        stp   x29, x30, [sp, -16]!

It may suffice to just teach it the new register names?

I’ve just had a look at Zap…

There are two ways of viewing assembler. The first is as a disassembly. This probably cannot be easily fixed as while it looks fairly simple to patch in support for the extra registers, what may be less simple is catering for dual-word width instructions. Still, that ought to be simpler than coping with Thumb!

The second way is source code. This is handled by ZapMJE and the parser is actually fairly simplistic and treats “things that aren’t otherwise handled” as names – this includes the registers (a rather literal interpretation of R0 being a name of something!). In this respect, it displays the AArch64 code correctly. ;-)
[it doesn’t like those C style comments, but since objasm doesn’t do that…]

what may be less simple is catering for dual-word width instructions

Of which there are precisely zero. All instructions are 32 bits wide.

The SVE extension does introduce the concept of “prefixed instructions”, where you can place a special instruction immediately before certain types of other instruction in order to modify their behaviour. But the instruction pair are still handled as two separate instructions by the assembler, so disassemblers should handle them separately as well.

Of which there are precisely zero.

Oh. I just kind of assumed 64 bit processor, 64 bit instruction (space for all those extra registers).
Well, if that’s the case, bring it on. Shouldn’t be too hard to teach Zap of the new register set (famous last words).

As a matter of interest – can you switch between 32bit and 64bit modes – and then back again?

The layout looks a lot like traditional ARM. It may suffice to just teach it the new register names?

Adding support for the new register names is indeed easy but there are also a lot of new instructions. If the layout is as ARM proposed (eg b.ne for bne) then that complicates things too.

Another consideration is whether or not you want the syntax highlighting to only colour instructions that are valid, ADDlt is valid in 32bit but not in 64bit.

Is there actually a 64-bit assembler available from somewhere, or is this discussion fairly academic at this point? A C compiler wouldn’t go amiss either :)

As a matter of interest – can you switch between 32bit and 64bit modes – and then back again?

Yes. However you can only do so if there’s a higher privilege level which is already running in 64bit mode – e.g. a 64bit hypervisor can run a mix of 32bit and 64bit OS’s, and a 64bit OS can run a mix of 32bit and 64bit user-mode apps.

Is there actually a 64-bit assembler available from somewhere, or is this discussion fairly academic at this point? A C compiler wouldn’t go amiss either :)

Mainstream compilers like clang & GCC have supported AArch64 for years.

However I don’t think any of the 64bit-supporting versions of those compilers have been ported to RISC OS yet, which makes things a bit awkward from the POV of wanting to start adding 64bit code to the ROM build system.

And of course none of the 64bit output those compilers produce will be designed to work with a 64bit version of RISC OS (since 64bit RISC OS doesn’t exist yet). But that might not necessarily be a problem, since we’re also yet to decide on what ABI/PCS a 64bit version of RISC OS should use. So a generic 64bit ABI/target like aarch64-arm-none-eabi (which most compilers should support) is probably as good a place to start as any.

Weeee the bit about a ‘hypervisor’ has gone in one ear and out the other :-(

Not something as simple a extra flag in msr cpsr,

You know how there’s a kernel that runs in a privileged mode and it controls the system and what can run and so on?

Well, a hypervisor is sort of like a kernel on top of the kernel. Instead of arbitrating applications, it deals with entire operating systems by treating the system as one or more virtual machines.