Apple's M1

Meanwhile Linux is on the way for the M1. Check out or even support the effort here

Excellent, an Apple M1 falling outside the walled garden!

Linux has now been ported to M1:

January 2021; How We Ported Linux to the M1
Quote: “…
To revert to booting MacOS, in 1TR open terminal and type bputil -n
…
We used a Raspberry Pi image because it was a live USB boot image, so we only had to make minor modifications to boot it.
…”

Jan 21, 2021, Linux has been ported to run on Apple’s M1 Macs

and just to prove it’s a popular processor:

Researchers have detected two malware strains that target Apple’s new M1 processors. The M1 system-on-a-chip (SoC) was launched late last year and is used in the most recent generations of MacBook Air, MacBook Pro, and Mac mini devices.

Having just come from the ARM Laptops topic…

Linux has now been ported to M1:

First Linux, next somewhat later: RISC OS – OK, just need to solve the whole 64 bit thing.

I thought it was stil capable of AARCH32 operation. So it appears it needs to wait on the next gen Operating System in the line of Acorn System OS, MOS, RISC OS, Whatever the 64-bit version following RISC OS is to be called.

Whatever the 64-bit version following RISC OS is to be called.

I vote for risC os, the emphasis being on C…I’ll get my coat

Well it’s an improvement over OISC OS, where the O stands for over-engineered!

(Edit: For the absence of doubt, I’m referring to AArch64 here)

Just call it OS and be done with it…

I vote for risC os, the emphasis being on C…

All the other “little parts” seem to be more numerous – does that reflect the amount of assembler?

Given that x86 Linux users complain about The Microsoft Tax, will ARM Linux users start complaining about The Apple Tax? (Or given that The Apple Tax is already a thing, perhaps the other Apple Tax.)

…we need to convince Apple that they’ll release an “Apple Pi” dev board with linux or whatever support…it’s even funny when you add the ‘e’ ;-) May be I should ask their marketing board to give me an assignment…

I thought it was stil capable of AARCH32 operation.

AFAIK, no Apple ARM silicon has supported Aarch32 for a long time, I think iOS 11 killed every trace of 32bit support. Especially in the new desktop/notebook line of SoCs, it would make absolutely no sense to put anything additional to Aarch64 into it – it would just make it more expensive to develop and to produce, and no software would use that part of the SoC.

Whatever the 64-bit version following RISC OS is to be called.

I suggest we follow the lead of Windows, Linux, iOS and Android when they added 64bit support and call it “RISC OS”.

I vote for risC os, the emphasis being on C

No-one would notice amongst all the other mis-spelling.

I suggest we follow the lead of Windows, Linux, iOS and Android when they added 64bit support and call it “RISC OS”.

None of those systems were hard tied to the ISA in any way shape or form. So I personally dissagree, though we will see how it works in time.

The only OS in the line that includes RISC OS that was independant of the CPU was MOS, and I do not suggest MOS being the name in any way. And MOS was usually rewritten for each supporting CPU (which is a long list), often only part needed rewritten for the CPU as most of the CPUs supported were through the Tube interface.

Also as for Windows and Linux x86, both of these still run software written and compiled for 32-bit PMODE operation, and do a good job of it (thanks to the high level of legacy compatibility in the Intel CISC). Though any line of CPUs that uses tables to the point of making things like the 0xFOOF Opcode bug possible are in question already.

I suggest we follow the lead of Windows, Linux, iOS and Android when they added 64bit support and call it “RISC OS”.

It is a splendid opportunity to get rid of that pesky half space and go for search engine friendly RISCOS.

It is a splendid opportunity to get rid of that pesky half space and go for search engine friendly RISCOS.

That brings me to a lot of Spanish and/or Portuguese articles about work-place safety (I think – my Portuguese is very rusty, and my Spanish was never any good to begin with). While I’m sure that these are informative, I think it would be safer keeping the space. ;)

I await the harder-hitting M1A2 Apple…

that was independant of the CPU was MOS

Not our MOS, it wasn’t. Quite some dependence on the X, Y, and A registers. Plus the MOS entry points basically working back from the 6502 hardware vectors at &FFFx.

MOS was usually rewritten for each supporting CPU

Not so much. It had to be compatible, it didn’t have to be exact. Wasn’t there a CP/M running on something like a Z80? And the ARM TUBE, with Brazil. And PanOS…

often only part needed rewritten for the CPU as most of the CPUs supported were through the Tube interface.

The Tube interface was well defined and essentially turned the “host” Beeb into a smart terminal, providing keyboard and file services to the co processor, and displaying the video output.
All that would need to be written is some glue code to talk through the Tube rather than directly to hardware. Given the proliferation of machines back then, it was pretty normal to have machine specific versions of things – the Amstrad CPC is not the same as an Osborne 1, even though they both run a 4MHz Z80…

go for search engine friendly RISCOS.

It’s very search engine friendly. Given that from time to time I (attempt to) read articles in El País, Google offers up a lot of links that are nothing to do with a certain ARM based operating system. :-)

While we’re at it, can we ask the Portuguese to spell risk with a K?

So are people of the opinion that AArch64 isn’t RISC? Even if the instruction set has grown, it shares the original philosophy of rationalizing the instruction set, so that you’re not wasting resources on instructions that don’t get used much (as opposed to x86 which is forever hampered by the need to support everything). Perhaps the R in AArch64 RISC OS could stand for “rationalized”?

AArch64 sure is RISC. Old hands are sad that it loses conditional execution on all instructions, multi-register load/store, all of which are heavily used in AArch32 code. But we understand why.

AArch64 sure is RISC

Calling any modern ARM “RISC” is really stretching the definition. It does after all mean “Reduced Instruction Set Computer”

At the time of ARM2, x86 had 100ish instructions. ARM now has hundreds and x86 has around 1500, so if you apply Moore’s Law to instruction sets, we can still call ARM “RISC” !

I personally don’t consider ARM RISC any more. RISC like, perhaps.

…may be all just a matter of definition and who defines it. I think one can see that besides Thumb (2 Byte per Instruction), the instruction length is still 4 Bytes, even with AArch64. So somebody is trying to keep that philosphy and the decoder. So the major difference to x86 is the instruction length and which instruction can access memory directly (in x86 you can do e.g. ADD [mem],x). But of course with all the v5/6, VFP, NEON, there’s a bit more than (good) old ARM2/3 times…but I’m super happy with that, as it really speeds things up.

…when I’m coding assembler on x86 I’m still surprised why they keep even the oldest 16 Bit instruction level inside the latest silicon…all those string instructions (stosb, lodsb,…), BCD and whatever can be perfectly executed on the latest AMD/Intel cores. When booting with FreeDOS from a USB stick, it’s perfectly okay to run a .com executable which uses 16 Bit mixed with the latest SSE4.x level instructions. My only guess is that some crappy thing inside even modern OS or hardware needs those…

RISC isn’t purely about the number of instructions, it’s about the complexity of the CPU. As Kuemmel says its still fixed length instructions and single cycle decode logic. The other key RISC attribute is all logic instructions are register to register, there is no CISC like mixing of operations on both registers and memory or memory and memory, everything has to be loaded to or stored from a register. Those registers are also general purpose, even more so in Aarch64 than Aarch32, unlike in CISC which often has registers which can only be used for special purposes and a far smaller number of general purpose registers.