Apple's M1
Kuemmel (439) 384 posts |
Meanwhile Linux is on the way for the M1. Check out or even support the effort here |
David J. Ruck (33) 1504 posts |
Excellent, an Apple M1 falling outside the walled garden! |
Glenn Moeller-Holst (8768) 16 posts |
Linux has now been ported to M1: January 2021; How We Ported Linux to the M1 Jan 21, 2021, Linux has been ported to run on Apple’s M1 Macs |
Alan Adams (2486) 1131 posts |
and just to prove it’s a popular processor:
|
David J. Ruck (33) 1504 posts |
Having just come from the ARM Laptops topic…
First Linux, |
Jon Abbott (1421) 2615 posts |
I vote for risC os, the emphasis being on C…I’ll get my coat |
Chris Mahoney (1684) 2125 posts |
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) |
Rick Murray (539) 13451 posts |
Just call it OS and be done with it… |
Steve Pampling (1551) 7977 posts |
All the other “little parts” seem to be more numerous – does that reflect the amount of assembler? |
Charlotte Benton (8631) 168 posts |
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.) |
Kuemmel (439) 384 posts |
…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… |
Steffen Huber (91) 1945 posts |
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.
I suggest we follow the lead of Windows, Linux, iOS and Android when they added 64bit support and call it “RISC OS”. |
Frederick Bambrough (1372) 826 posts |
No-one would notice amongst all the other mis-spelling. |
John Rickman (71) 632 posts |
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. |
Andreas Skyman (8677) 170 posts |
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. ;) |
Stuart Swales (1481) 351 posts |
I await the harder-hitting M1A2 Apple… |
Rick Murray (539) 13451 posts |
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.
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…
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.
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. :-) |
Charlotte Benton (8631) 168 posts |
While we’re at it, can we ask the Portuguese to spell risk with a K? |
Charlotte Benton (8631) 168 posts |
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”? |
Stuart Swales (1481) 351 posts |
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. |
Jon Abbott (1421) 2615 posts |
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. |
Kuemmel (439) 384 posts |
…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… |
David J. Ruck (33) 1504 posts |
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. |
Colin Ferris (399) 1756 posts |
Perhaps some examples of 64bit ARM assembler would be interesting to show a way of going from 26 bit code to 64bit. Without spilling people’s tea :-) |
Rick Murray (539) 13451 posts |
Change the compiler options and then build all. If it’s harder than that, you’re doing it wrong… To better answer your question, it’s not so much a matter of what 64 bit offers as what it has taken away, which is one of the reasons that us grey haired gits (“get off my lawn!”) don’t consider it to be “ARM”. Let’s see… Conditional execution, load and store multiple, and directly fiddling with PC as three examples. So it’s not such a matter of switching register names (no more ‘R1’ stuff, it’s W or X now) and working out the peculiarities of the new instruction set… it’s more a case of entirely rethinking how something is done. You can’t do jump tables like this any more: LDR PC, [PC, R0, LSL#2] And a simple CMP followed by something that is EQ or NE (or whatever)? If it’s not a branch it’s a no go. So a lot of stuff will need to be rewritten, more or less completely. |