Norcroft 64

“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.

Curiouser and curiouser!

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.

The problem is that you need humans to do the remaining 30% or 40% – which means they have to be able to understand both the original and the machine-converted result, so as to identify every deficiency in the conversion.

I looked at this some years back in the context of Visual Basic 6 needing to be converted to VB .Net. It was just not possible on anything except trivial examples, because they are completely different languages. Granted, ARM 32b and 64b assembly language shouldn’t be nearly different; but the same basic consideration applies.

I wonder if the Author of RPCemu could be persuaded to modify it – to use ARM64 switching from 64 to 32 and back with the MSR command.

The source is available, and the development environment is massively difficult to set up.
I seem to recall there being mention of quiet, backroom, development of a non-RPC emulator which interested parties might co-operate on.

to use x86 switching from x86 to ARM and back with the MSR command.

I’ve modified your request to highlight what you’re actually asking here…

of quiet, backroom, development of a non-RPC emulator

I hope so.

which interested parties might co-operate on.

I’d offer to test, but new stuff doesn’t tend to want to work on the dinosaur that is XP.

quiet, backroom, development of a non-RPC emulator which interested parties might co-operate on

Perhaps, if they knew about it!

“Dr. Strangelove points out that such a doomsday machine would only be an effective deterrent if everyone knew about it; de Sadeski replies that the Soviet Premier had planned to reveal its existence to the world the following week at the Party Congress.”

if everyone knew about it

This is RISC OS. Saying anything beforehand is verboten. Why d’you think we have two stacks? ;)

Perhaps, if they knew about it!

As I recall Peter mentioned it here, I can’t think where else I’d have picked up any such idea.
The RPCEmu mailing list would be one method of contact I suppose.

I’d offer to test, but new stuff doesn’t tend to want to work on the dinosaur that is XP.

Current RPCEmu is built using QT5.
Incompatibility with XP comes in at QT5.7 but 5.6 is available for download so you could have a play.

As I recall Peter mentioned it here, I can’t think where else I’d have picked up any such idea.

I think that Peter was referring to getting the JIT working for RPCEmu on Mac with AArch64, not an AArch64 or non-RPC emulator.

I wonder if the Author of RPCemu could be persuaded to modify it – to use ARM64 switching from 64 to 32 and back with the MSR command.

I seem to recall there being mention of quiet, backroom, development of a non-RPC emulator which interested parties might co-operate on.

As I recall Peter mentioned it here, I can’t think where else I’d have picked up any such idea.

I think I shall add today to my list of days where I have no idea what’s going on. I suppose if there’s a secret backroom emulator group going I’m not a member, or perhaps it’s so secret that I’ve not been told I’m a member….

or perhaps it’s so secret that I’ve not been told I’m a member….

This is the most likely option XD

I suppose if there’s a secret backroom emulator group going I’m not a member, or perhaps it’s so secret that I’ve not been told I’m a member….

In which case, I’m misremembering and RPCEmu development appears to have ceased in (quick check) 2021

and RPCEmu development appears to have ceased in (quick check) 2021

Merely between releases, not ended.

New RPCEmu releases usually appear at the London Show each year, but there hasn’t been one for two years, so I blame the show organisers. They really need to pull their fingers out… ;-)

This is RISC OS. Saying anything beforehand is verboten. Why d’you think we have two stacks? ;)

Sadly that’s not the reason :-(

https://www.riscosopen.org/forum/forums/5/topics/17603#posts-136572

I can imagine Rick’s cats tail wagging furiously – at my suggestion:-)

I not too sure why a big change is needed to the Emulators – ie changing to a later module of Pi.

512Mb or more of Ram would be nice – but I can see people here spilling their tea!

Can’t be done – bit of Brunel there.

Merry Xmas all – and a healthy New Year.

Internally, the Pi is very different to the RiscPC. It’s not so much changing an existing emulator as writing a new one.

My “x86” comment still stands. The Pi is not a jazzed up RiscPC, AArch64 is not jazzed up ARM-as-we-know-it.

My cat (Anna) doesn’t care about computers except for when I’m attending to my phone and not her. Then she gets annoyed, for one must treat gods with the appropriate level of reverence (and crunchies).

Here’s something to consider over a mince pie, Colin.

The StrongARM Data Sheet is 64 pages. I haven’t been able to find the ARMv4 Architecture Reference Manual, but the much later ARMv6 one that covers it is 1138 pages, so my guess is the ARMv4 one was probably 25% of that size. [From around the same time, the ARM 7500 SoC full data sheet was 328pp.]

The ARMv8 Architecture Reference Manual is 8696 pages. ARMv8 ARM does not even describe a usable chip, just a ‘processing element’ that can be integrated onto one.

Clearly it is trivial to ‘drop in’ such a new CPU into an emulator ;-) And that’s before you start to emulate the system elements.

I think it would be far easier to add the currently un-implemented hardware to qemu-system-arm than modify RPCEmu. (Start with the QA7 interface to the clock.)

There’s also qemu-system-aarch64.

I think it would be far easier to add the currently un-implemented hardware to qemu-system-arm than modify RPCEmu

Of course it would. Is anyone doing it? Does anyone plan to do it? Tumbleweed…

Of course it would. Is anyone doing it? Does anyone plan to do it? Tumbleweed…

Amen to this.

I think it would be far easier to add the currently un-implemented hardware to qemu-system-arm than modify RPCEmu.

QTEmu for the frontend I suppose, although I would have thought that first attempts would be easier if the RPi emulation was used as, allegedly, that is mostly bootable.

The ARMv8 Architecture Reference Manual is 8696 pages.

What, is it written in crayon or something?

It’s a core for a processor that is supposed to be sort of RISC, how the hell does that alone get to eight and a half thousand pages?

written in crayon or something?

ROFL.

Today’s ARMv8 Instruction Set Architecture introductory guide is 38pp.

1986’s VL86C010 (ARM2) data from VLSI book with all instructions, bus timing diagrams etc. was 50pp.