Apple's M1
|
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 :-) |
|
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. |
|
@Colin: Pretty much what Rick said…I’m currently diving into that by playing with some small examples written on Linux AArch64. A nice overview from ARM is this presentation. Check page 31ff …your new friend for conditional execution is called “CSEL”…not much left of the old times in that respect…but it keeps my brain from becoming too ‘rusty’, if you can say that in english… |
|
Yes it is that RISC has little to do with the number of instructions, rather the complexity of each instruction. Hence why we do not have anything like DBcc from the 680×0 world, as this is a long running state change operation that is fairly complex in nature. The complexity of each instruction is decreased (Reduced) so that it is simpler to implement in a way that is more about HW states, and in general executes more effeciently (in general, we do now have Divide ops). Also this generally leads to a load/store archetecture, that is one where nearly all operations are done register to register, with load and store being the only operations that touch memory. We used to have SWP that bent the rules on this, and some argue that the LDM/STM operations are not very RISC. Now SWP has been replaced by the LDREX/STREX/CLREX instructions, because no one wanted to use the external signal of SWP to correctly implement bus mastering for multiple CPUs (again simplifying HW as is what RISC is mostly about). I will attempt not to mention personal opinions to much on this issue. For that I am still working on the documentation of one good method of implementing super scalar operation of the ARM AARCH32 ISA, in a way that avoids the majority of stall cases, and dependancy delay cases. I feel that the AARCH32 ISA as it is now known, what we call ARM or ARM 32bit (26bit), etc, is very well suited to super scalar operation, and there are a lot of university research to back that belief. I am looking forward still to future, better ARM 32bit designs to keep the traditional RISC OS going far into the future, whith up to 32TB of RAM, so very
Having played a little with AARCH64 assembly, it is far enough different from ARM 32bit assembly (including the combined R15+PSR [‘26 bit’] stuff) that it may as well be a different CPU. It is as easy to go from ARM 32bit code to AARCH64 as it is to go from ARM32 to MIPS (or to PowerPC, or to 680×0, or to AMD64/IA64, etc). So not so easy as it were. Though thanks to the chosen nmemonics the Assembly Language of AARCH64 almost looks like it is related to AARCH32 ARM 32bit. It is not as related as it almost looks, there are no conditional per operation, branching is handled differently, etc, etc.
Assuming you are using UAL syntax, and only a very small subset of the instruction set. As it was specifically mentioned Assembly.
Not ot mention the incompatibility of any Operation at all. The instruction set is different enough to be a different CPU. Yes it is the next offerring from ARM, so in name it is ARM, though the ISA is nothing like what we are accustomed to. Hence the insanity of wanting to rewrite the entire OS in C. Which I am all for, so long as we keep the assembly version around for ARM 32bit systems [and take the time to orginize it better if going through the entire source anyway as it were]. It would be great to have an OS similar to RISC OS (regardless of name) that works on those CPUs that are AARCH64 only ARM. For compatibility with RISC OS though, that is another issue. Apparently some of the AARCH64 CPUs still have the ability to run some user mode AARCH32 code, though only user mode and with some limits. |
|
Obviously, more registers means more bits required to encode them in instructions so its no wonder that they had to drop conditional execution. Anyway, I never have enough registers when trying to optimize routines in assembler so I think it’s a good tradeoff. Looking at this document, you can still use branch table but you need 3 instructions ADR, ADD, BR. The most curious part is the alignment requirements of SP. I would have understood 8-bytes since it uses 64-bit registers but 16-bytes ? |
|
The FP/SIMD registers are 128 bits wide, and need to be stored at their natural alignment on the stack. |
|
ARM – the original instruction set, was designed by a human for humans. It’s very elegant and allows for very optimal code, that’s easy to read/follow. I expect AARCH64 was vicariously designed by a C compiler, where conditional instructions are just an unnecessary complication. I know that if I were designing a modern CPU instruction set, I’d base it heavily on statistical analysis of the target OS’s codebase. |
|
How about an AARCH64 version of the OS gets called RISCish OS? |
|
I don’t really care what it’s called, but if it gets done I shall be Very Impressed Indeed. If it’s got functional !Draw, !Zap, and BBC BASIC I shall be even impresseder! |
|
I agree with this statement quite completely.
And this one as well. The amount of work involved in creating the new system is monumental, and to also port the most important applications is a job of super-human proportions. As the ISA is no longer similar to what we are familiar with. |
|
I vote for “Arthur 2” ;-) |
|
That I really like the sounds of :) . |
|
Shouldn’t that be “Arthur 3”? But it gets complicated since “Arthur” is “RISC OS 1”…so RISC OS 3 would already be Arthur 3, we’re now on Arthur 5, and Arthur SIX is already taken, so probably “Arthur 7”? I would suggest “RISC OS Reloaded” instead. Then we already know what we call the 128bit variant: “RISC OS Revolution” :-) |
|
RISC OS Insurrection :) |
|
Darned pop culture references, I did not get them when I was in my teens, twenties, or thirties, and still have to look them up. |
|
To put it VERY mildly! |
|
Maybe. It is just a little further removed from AARCH32 ARM than AMD64/IA64 is removed from AARCH32 ARM :) . At least the AMD (licensed to Intel) ISA has MOVcc conditional operations. These actually originate in the older Intel (licensed to AMD) ISA starting with the P5 generation of CPUs. |
|
Can’t believe you’ve never seen The Matrix. Add that to your bucket list (but only The Matrix, the two sequels are optional and very Marmite 1). Steve is likely referring to one of the Star Trek movies. And I will take it in a different direction by suggesting: RISC OS Salvation ;-) 1 It’s a British yeast extract gloop with a pungent odour and matching taste that a lot of people spread on toast for some reason. It is also notorious for nobody being “meh” about Marmite. You either love it or hate it, with no in between. The Aussie version is called Vegemite. |
|
I know that wasn’t addressed to me, but I for one have never seen The Matrix. I’ve seen Blade Runner, and Easy Rider, and A Passage to India. Oh, and Tommy the Toreador, The Court Jester, South Pacific, and Oklahoma – the last four when I was just a little kid. |
|
How about “I Can’t Believe It’s Not RISC OS”? |
|
Of course thinking about how similar different modern ISAs are, perhaps it would be better to target MIPS (32 and 64 bit) than AARCH64 for the next generation, at least it is a lot closer to ARM 32bit. Or if you want to go further off of ARM without going as far as AARCH64 in similarity of ISA then perhaps CISC OS on the IA/AMD64 ISA? Or others that are as close as MIPS to ARM 32bit would be Parallax Propeller, PowerPC, or 680×0 (the last making for another CISC OS). Just ideas for things closer to ARM 32bit ISA than AARCH64 is. At least as far as the 32bit and 64bit ISAs that I have personal experience with programming for. There are also a few that are further from ARM, not mentioned here. |
|
Can I suggest porting RISC OS to the Maxim MaxQ? It shouldn’t be too hard, this processor only has one instruction. https://www.maximintegrated.com/en/design/technical-documents/app-notes/3/3222.html |
|
I heard about the Beatles some time in the 60s. I have even heard the Rolling Stones, once at the Sussex University summer ball, before they were famous, and once at a concert in Aarhus. My daughters gave me a tape to play in the car when I was on the school run: Crowded House, Jethro Tull et al. Apart from that I am totally ignorant of popular music. I have not been to a cinema for thirty years, because I always found the sound-volume actually painful. I wonder how often cinemas are prosecuted for for breaking public health by-laws on sound-levels? Besides, who needs cinemas when there is YouTube where you can set your own sound levels, and not have to wade through other people’s popcorn.
Snap. Not seen the others, though. My impression is that there is too much action in a lot of modern films. You can hardly tell whether you are watching human beings or frenetic cartoon characters. Just compare Mizoguchi’s The 47 Ronin (1941), how superior it is to later remakes. |
|
I do think you found the one CPU least like the ARM 32bit. I do not think there is one more different in all the world. Not only is it not 32-bit, but the ISA is unlike anything I have ever worked with. It is technically a load/store archetecture CPU, though as the operation is target register based (kind of like rotate and shift in the appollo guidence computer), I do not know if it is RISC in the traditional sense. I guess that each instruction is as simple as it can be though. And counting the load, and store formats I would say it has 3 instructions, though only one operating instruction. I thought that the classic IA32 and 16 bit 8086 ISAs were bad in the limitiation of register usage. To require certain that only a specific different register be used for each operation is restriction of register usage to the extreme. Honestly I think this is why people like the AMD64/IA64 stuff, it does not have the register usage restrictions of 80×86 based CPUs. Knowing the CPUs to come before it, and contemperary to it, anyone that sais the 8086 ISA was meant to be used by humans is must love to tourcher themselves. That ISA is terrible, though ironically not the worse I have seen. And if you attempt to say that 80×86 PMODE was meant for human porgrammers, I will know that you enjoy pain to an extreme. Now ARM AARCH32 that is a human usable ISA, same goes for ARM ARCH64, though I see a lot of lost opertunity (even for writing compilers) in the AARCH64 ISA. I do wonder if there is a tendancy not to use the extended features of the ARM ISA by compiler writers because of the lack of equilivents in most CPUs? I do think a compiler could (and have seen such) could take advantage of the conditional execution, and free shift to better optimize code, same goes for the direct access to the Program Counter (R15). One rule that so far has not been broken is: if you want many to use a CPU or MCU, make sure the documentation is there for them to write assembly language applicaitons. I think this is why a couple of multi core closed ISA MCUs failed. They only allowed the use of high level languages (usually C and C++). While just about every CPU/MPU and MCU that provides for assembly language use (including those that have a convoluted ISA) has succeeded to some degree. And I have seen some odd balls (especially some of the 32-bit stack machines in HW). |
|
Two for the price of one (STNG and Jan 6th). 1 Change Authorisation Board, for items that have, or could have, a significant impact. 2 13 Changes listed, 9 were from the Network Team and 7 were mine.3 3 They missed me while I was off sick :) 4 Not even in a severely distorting looking glass… |