Norcroft 64

Is there an ARM64 assembler, that uses the same syntax as the DDE assembler

I am pretty sure that at this point ROOL is working on this ;)

or can the DDE assembler be made to output ARM64 instructions?

Everything can be made to emit ARM64 or even x86 instructions etc. An Assembler, as the name implies, takes machine language expressed in a “mnemonic” form (something relatively easy for humans to read and make sense of, but that still express machine-level code) and “encodes” it into the binary form of machine code. Countrary to compilers, an assembler (generally, but not always) encodes 1-to-1 the assembly source into machine language.

So, indeed DDE can be extended to emit ARM64 binaries. That doesn’t means it will also automatically convert ARM32 into ARM64, that requires either a translator or humans to convert the ARM32 sources into ARM64 sources.

HTH

can the DDE assembler be made to output ARM64 instructions?

If you don’t mind some macro soup, you can get AArch64 code out of current ObjAsm to a limited degree. For example

        MACRO
        SWIa64  $swi
        ASSERT  $swi < &10000
        DCI     &D4000001 :OR: ($swi :SHL: 5)
        MEND

The wheels fall off with this technique as soon as you need to refer to external symbols, because the linker doesn’t know how to patch them up, but it does mean that (according to the file date stamp) I have the dubious honour of having created the first RISC OS program for AArch64 on 28-Dec-2020 at 09:47. Nearly 3 years later, still waiting for an OS to run it on…

That’s only one notch up from toggling it in on the front panel in binary!

ISTR Tim writing the 8051 microcontroller code for A3000 keyboard in AAsm using macros.

At the RISC of being shot down in firey balls of flames…

I’ve been looking at the possibilities of converting the vast amounts of ARM32 assembler to ARM64 assembler….
- at this stage it’s just for my fun and entertainment… and also quite a good learning experience for a number of things…

So, I now have some Python scripts that convert Acron Arm assembler into ARM64 assembler
- I can show a few snippets if you’re interested…but this may not the right forum… Code Review better?

Anyway….
- I’m using the GNU Assembler as this seems to be the most easily available…

Obviously some of the syntax is different between this and the Acorn / DDE assembler…

My current code will transtate several of the assembler directives..

But at this stage, I need to make the decision of which way to go
1) translate everything into GNU assembler syntax
2) Use an ARM64 version of the Acorn/ARM Assembler…

If it’s (2), then it’s a lot easier, for Macros etc…

It so happens that the official ARM Assembler seems to be a direct correspondent…

https://developer.arm.com/documentation/dui0041/c/Assembler?lang=en
https://developer.arm.com/downloads/search?type=Software+Development+Tools&type=Software
https://developer.arm.com/documentation/ka005198/1-0/?lang=en

… but so far, I have failed miserably in getting accepted into the ARM Developer Program…

So, if the DDE assembler was heading in this direction, then that would be ideal!

There was a advert for a ARM64 assembler book – the author waxed lyrical about the advantages of 64bit above 32bit.

I can imagine Rick sitting there – stroking his cat Purr Purr :-)

From James Bond!

There was a advert for a ARM64 assembler book – the author waxed lyrical about the advantages of 64bit above 32bit

To be fair, it would not be much of a book if you just go “Nah, don’t bother with this newfangled AArch64 stuff, I miss LDM/STM, conditional instruction execution and all that other great stuff that AArch32 did”.

the author waxed lyrical

Everything is the greatest thing since sliced bread…until something better comes along.

What are the benefits asides from:

• Your pointer is bigger
• Simpler instruction set (which can be quicker to decode, and less if that conditional malarkey)
• Can address tonnes of memory without trickery
• Loads more registers
• Meaning, ultimately, more oomph for less power

I miss LDM/STM, conditional instruction execution and all that other great stuff that AArch32 did

Yup. All of that.

I can imagine Rick sitting there – stroking his cat

😸

(and if RISC OS properly supported Unicode, maybe emojis would work too ;p )

@ Martin P.

So, I now have some Python scripts that convert Acron Arm assembler into ARM64 assembler
- I can show a few snippets if you’re interested…but this may not the right forum… Code Review better?

Yes probably code review is a better place for this chat, which is certainly very interesting, so I don’t see why you have any RISC to be shot down ;)

Like you, I’ve created an AArch32 to AArch64 translator in Python, chosen for its robust support in GitHub and GitLab automations. The goal is to upload ARM32 code and automatically generate a corresponding ARM64 source tree.

- I’m using the GNU Assembler as this seems to be the most easily available…

I also use the GNU Assembler, which seems the most accessible option while awaiting official AArch64 support from DDE. My translator not only converts AArch32 to AArch64 but also translates ObjASM dialect to GCC, including macro support. However, I’m tackling challenges like accurate register handling—trivial for user-space applications but complex in privileged mode. I’m currently integrating rulesets to automate and refine the translation process, addressing specific issues like r12 translation and backed registers.

But at this stage, I need to make the decision of which way to go
1) translate everything into GNU assembler syntax
2) Use an ARM64 version of the Acorn/ARM Assembler…

Regarding your dilemma between translating everything into GNU assembler syntax or using an ARM64 version of the Acorn/ARM Assembler, why not consider both? In regions like the Far East, there’s significant interest in translating ARM32 to ARM64, particularly GCC and user-space code. While ARM’s original assembler evolved from ObjASM, their trajectory has shifted towards KEIL and now supports both LLVM and GCC. Targeting GCC ASM could broaden your project’s appeal.

Many still use ARM32 written in ObjASM syntax. Plus, if you aim to translate RISC OS, collaborating with the RISC OS Open Ltd (ROOL) team could provide invaluable insights. Experts like Jeffrey, Sprow, and Ben (and others) might offer in-depth knowledge on the nuances of ARM32 to ARM64 translation for RISC OS.

I’m designing my translator to accommodate both approaches and currently use GCC to evaluate translation quality. I plan to open-source it once I conclude my active development.

but so far, I have failed miserably in getting accepted into the ARM Developer Program

I am not following the latest trend, but what is the issue? It traditionally involved a simple registration process, which still seems to be there:

https://www.arm.com/resources/developer-program?#register

If you have twitter and you do not know already, you can also follow their tweeter account here:

https://twitter.com/ArmSoftwareDev

There is also a discord channel which is pretty active and you could ask for help there.

Policies might have changed, but I’m confident the community or ARM’s support can guide you through any recent updates.

HTH

The goal is to upload ARM32 code and automatically generate a corresponding ARM64 source tree.

There’s an ARM document on migrating code from 32 to 64.

It says: Don’t automate it.
And then: Seriously, don’t.

;)

The folks at ARM took advantage of the switch to 64-bit to optimize the instruction set for modern workloads and modern CPU architectures..
- so, expanded register set
- floating point included as part of the instruction set

I believe conditional execution was problematic for modern superscaler / out-of-order pipelines too…

I believe conditional execution was problematic for modern superscaler / out-of-order pipelines too…

Correct and also to make the entire architecture microcode based, I have explained how the conditional bits were processed (after the PLA based decoding) in another topic (in Aldershot I think), so they could invalidate the instruction after it was decoded, which with the introduction of thechnologies as you’ve mentioned, gave no advantages at all compared to ARM2 times.

There’s an ARM document on migrating code from 32 to 64.

It says: Don’t automate it.
And then: Seriously, don’t.

Let me have a look… hummmm…. it doesn’t mention for fun, hummm oh wait… for fun is allowed! Hurray! XD

@ Paolo Z

Yes probably code review is a better place for this chat, which is certainly very interesting, so I don’t see why you have any RISC to be shot down ;)

Do you want to start a Aarch32→Aarch64 thread in Code Review?

Like you, I’ve created an AArch32 to AArch64 translator in Python, chosen for its robust support in GitHub and GitLab automations. The goal is to upload ARM32 code and automatically generate a corresponding ARM64 source tree.

Sounds like you have a good plan in place
- my ambitions are much more modest!

About the different assembler
- it would be just easier if I didn’t have to translate all the ^ * & operators… as I don’t think GNU has direct equivalents of all of them
- anyway, more to discuss on the other thread!

About Registering with ARM..

I went through the registration process, but have been stuck here for 10 days!

Your account is almost set up, however, before you can use it, we need to review the details to comply with export regulations. This can take up to 5 working days. If after 5 working days you are not able to log in, let us know using onlinesupport@arm.com.

- no amount of proding seems to stir them in to action!

Everything is the greatest thing since sliced bread

Which is only “good” in as much as the slice thickness is pretty even.
Everything else about is sort of an attempt to lower the lowest common denominator.

Is it just me or is working to replicate Aarch32 assembler in Aarch64 assembler basically taking the worst of both worlds?
Assembler – doing things the hard way
Aarch64 – dumping the elegance of the original.
While working in a higher level language, moves the bits that might confuse/annoy out of sight

Is it just me or is working to replicate Aarch32 assembler in Aarch64 assembler basically taking the worst of both worlds?

And if successful, yay, two code bases to maintain!

@ Martin P.

Do you want to start a Aarch32→Aarch64 thread in Code Review?

I think it would be best. But given few here are also very very focused on RISC OS only (you can see this from some of the comments), I’d suggest to bring this discussion in some other forums alltogether, otherwise it will unavoidably steer folks that want to push an opinion at every costs (we had like a month or so of someone posting in almost every topic pushing for stuff he clearly did not understand well)

Sounds like you have a good plan in place
- my ambitions are much more modest!

No, I am just having fun playing with stuff I enjoy, that’s all.

- no amount of proding seems to stir them in to action!

Hummm weird, they used to be relatively fast. Maybe it’s because we are under the holidays season?

I’ll have a check on the discord channel to see if there is any problem going on.

@ Steve P.

Is it just me or is working to replicate Aarch32 assembler in Aarch64 assembler basically taking the worst of both worlds?

In my case, yes it’s just you, sorry my friend. But again, personally I am only having fun. The guys serious about RISC OS are ROOL/ROD etc. I am just a user enjoying it for fun.

While working in a higher level language, moves the bits that might confuse/annoy out of sight

Sounds like another question for ROOL/ROD. What I can say as a professional software engineer is that what you’re asking for is going to cost money and time (and resources). So, I guess you know how to find all of the above, right?

Also rewriting RISC OS in a “higher level” language (do you mean Forth by chance? ;) ) will unavoidably lead to a different OS and so, as I have mentioned too many times already, ROOL will probably need to develop a “proxy ABI” to keep compatibility with the past. So, yes you’ll probably end up having 2 ABIs anyway. In this case, the best bet is that the AArch64 ABI will be as close as possible to the old AArch32 ABI (at least in the formal definition), otherwise folks will go nuts figuring out how to support both.

It’s not just a question of “higher-level” language. Rewriting it in C doesn’t warrantee portability, so you probably meant “rewriting it in a portable C” like Linux has been developed for YEARS. Then you need to add the time of debugging YOUNG code, and finally addressing the elephant in the room: Security.

One way to do all of the above and in an incremental form, is to start defocusing from the phrase “let’s rewrite it in C”, and actually start thinking of a complete strategy. For example:

1) Start adopting EL2 for the new kernel code and slowly move logic from the EL1 old Kernel to the El2 portion
2) Ensure that the EL2 portion works as a monolithic hypervisor.
3) Ensure that the EL1 ABI is left as it was while transitioning release after release more logic to EL2
4) Write EL2 in a higher level language to improve maintainability
5) Design a new ABI for the EL1 in AArch64 mode and overtime relegate the old ABI to emulation only (aka it will have to be deprecated at some point aka: do not write anymore Apps that require EL1 traditional RISC OS ABI)

Now, this is a superficial example of what could be done incrementally, so that people can measure things as they move forward. This approach also allows to benefits from ARM CPU that still support AArch32 in user space.

This is my 0.2c (otherwise Rick can go funky if I say 0.5c lol), probably he would also like me to add p! However, let’s note: I am not pretending to tell ROOL/ROD how to do their job, so these are just my thoughts.

HTH

ISTR Tim writing the 8051 microcontroller code for A3000 keyboard in AAsm using macros.

I remember seeing that and my brain went gloopy… but I don’t remember where I saw it. I suspect it was part of the <hic>other source release</hic>.

If you have twitter and

If you don’t have Twitter and you get a stupid login prompt, replace “twitter.com” with “nitter.net”…

I believe conditional execution was problematic for modern superscaler / out-of-order pipelines too…

That wouldn’t surprise me. It must have been a nightmare trying to predict in advance when that little CMP could change everything that follows…

we need to review the details to comply with export regulations

FFS. Is this for downloading a datasheet? Try Google instead…

Here’s the porting guide.

- no amount of proding seems to stir them in to action!

Maybe you aren’t interested in baking a billion pieces of silicon so…?

Long time ago when I contacted Texas about datasheets for the SoC in my PVR, I was basically told to get lost as they just weren’t interested in non-corporates. I think they opened up a little more when the OMAP got used in the Beagleboard and people kind of wanted info on the hardware.

Is it just me or is working to replicate Aarch32 assembler in Aarch64 assembler basically taking the worst of both worlds?

I think so. It’s also replicating the design mistakes of the past in shiny new code.

But, as Paolo has pointed out loads of times, it’s for personal amusement so more power to him. His screwy sense of what’s “fun” sort of aligns with mine. The only reason I’m not getting more interested in this is because I really don’t feel like learning the ins and outs of another processor. If it can’t run code written in C, I’m not interested. ;)

What I can say as a professional software engineer is that what you’re asking for is going to cost money and time (and resources).

That’s the thing. This shiny new 64 bit OS isn’t going to be written. Lack of money, resources, time, etc etc.

will unavoidably lead to a different OS

The ARM64 world is different enough that this would happen anyway, surely?

Rewriting it in C doesn’t warrantee portability

This. Like Linux, one needs to use specific data types, for example. It’s a lesson I learned a long time ago when I used “int” (as that’s what a lot of the RISC OS code that I’d seen did) and I didn’t quite appreciate that “int” == “long” on RISC OS. When my code was built with TurboC++, it went haywire because “int” there maxes out at ~32K (if signed) or 64K (if not); in a DOS world, “int” != “long”. And in a Windows environment, “it depends”.
Which is why code elsewhere uses definitions like “uint8”, because it’s a bunch of macros that provide exact types in a consistent way.

And that’s just an integer variable which is a pretty insignificant little thing really. There are plenty of other gotchas. That’s why the POSIX model exists – some sort of platform commonality.

Now, this is a superficial example of what could be done incrementally

Makes sense. The cold hard reality is that a 64 bit OS isn’t going to suddenly appear. So doing it bit by bit would seem to be the most logical approach – it’s also the least “expensive” one if things don’t work as problems can be seen before an entire OS has been written (<hic>ARX?</hic>), so alternative ideas can be looked it.

and finally addressing the elephant in the room: Security.

This is RISC OS. There has always been a troupe of fluorescent magenta elephants with Boris-mop-wigs pole-dancing in the middle of the room. We all try really hard not to notice them, but the 70s disco they’re dancing to is getting really annoying.

This is my 0.2c (otherwise Rick can go funky if I say 0.5c lol),

Hmm, have you corrected your tuppence-in-euro-cents for inflation? ;p

Anyway…

If it’s fun, then enjoy yourself – I can understand the intellectual appeal.

FFS. Is this for downloading a datasheet? Try Google instead

It’s not the documention I need
- the documentation on-line is actually quite good…

I’ve read the Porting guide
- it gave me hope that it was possible…

So, I figured this is the compiler/assembler I need:
https://developer.arm.com/downloads/view/ACOMPE
- or at least see if I can down load it, figure out if it runs under windows or linux etc

- from the documentation here:
https://developer.arm.com/documentation/dui0801/l?lang=en
- it seems to be very much a modern/current 32/64-bit version of the Acorn assembler…

Also, I didn’t feel it was impossible to go ahead with translating the current ARM asm to the GNU Asm (GAS)
- just it would be a fair amount of work..
- and I’d feel a bit of a fool if there was a compatible 64-bit assembler already available from ARM or ROOL/ROG or whoever…
;)

If it’s fun, then enjoy yourself – I can understand the intellectual appeal.

Thanks! :)

The cold hard reality is that a 64 bit OS isn’t going to suddenly appear.

200% agreed.

it’s also the least “expensive” one if things don’t work as problems can be seen before an entire OS has been written (ARX?), so alternative ideas can be looked it.

Exactly!

…We all try really hard not to notice them, but the 70s disco they’re dancing to is getting really annoying.

XD – You know I am going to steal this definition of RO ;)

- it gave me hope that it was possible…

It is, and even if it isn’t, you’ll learn a ton in the process, so you won’t lose anything.

There are things that makes no sense “technologically” speaking. But those are when people are trying to do things that are too far away from what a given technology allow us to do.

In the case of converting AArch32 to AArch64 sources, you have all the time you can possibly want, so design a 6 stages translator, or even 20 or 40, it will still be way faster than humans can do translating all the AArch32 sources manually. This is the key. And even if it can do only 60% or 70% of the work, still a useful tool compared to having to have humans doing 100% of the work.

So, I figured this is the compiler/assembler I need:

ACOMPE is available for free, but you’ll need an account yes. I have ACOMPE, I used the Linux x86_64 version in some projects, so until you have an account, if you have questions, I can be of help.

just it would be a fair amount of work..

It is.

Well, it’s good to hear it’s available for free… now all I need to do is get hold of it…

How about the ROOL/ROG efforts? Do you know if they have 64-bit compiler assemblers?

How about the ROOL/ROG efforts? Do you know if they have 64-bit compiler assemblers?

No idea TBH. ROOL teased a Norcroft C compiling to AArch64, but they showed only a DecAOF output, so AFAIU, they have a C compiler that can emit AOF 64bit, they have DecAOF that can disassemble AArch64 AOF. But no signs of a Linker(64) or an ObjASM(64) or even a way to test the “output”, because, well… RISC OS is still AArch32 ;)

If you read the message in the original post on the Iconbar, Mr. Steve R. (I presume) with his usual suttle humor also teased a possible ETA:

“You are about to show me shadows of the things that have not happened, but will happen in the time before us”, said Scrooge to the ghost of Christmas Yet To Come.

So, if I read between the lines correctly, a possible ETA for this is XMas 2024? Or, something undefined within 2024/2025 (or maybe it’s 2520 XD)

But it’s good to see effort is going on, so keep going ROOL! It’s a good way to close 2023.