Sinisterly
[Assembly] ARM or x86? - Printable Version

+- Sinisterly (https://sinister.ly)
+-- Forum: Coding (https://sinister.ly/Forum-Coding)
+--- Forum: Assembly (https://sinister.ly/Forum-Assembly)
+--- Thread: [Assembly] ARM or x86? (/Thread-Assembly-ARM-or-x86)

[Assembly] ARM or x86? - phyrrus9 - 01-18-2018

So, I want to know what your thoughts are on architectures. Not just limited to programming.

Reasons why I like ARM:

1. Fixed length instruction set
In ARM, every instruction is 32 bits long, this both speeds up instruction decoding but also allows you (the programmer) greater control over your code. You can easily modify your own code at runtime without having to worry about instruction fetches and decoding to determine length

2. Streamlined pipeline
Again a feature restricted to the RISC world is a multistage offset pipeline. This means that an ARM core can control completely what gets executed in what timeline. The way an x86 pipeline works is by using simply edge triggers or delays and locks to determine when to execute things. ARM does it different, the clock rate is fixed and thus offsets can be made so that multiple clock signals can be derrived from a single, ensuring that all instructions get executed in a single cycle (rather than as many cycles as 28 with x86)

3. conditional execution
Here is a pretty simple C program I want to show you:
Code:
void fnc() {     int i;     for (i = 1000; i > 0; --i)          sub1(i); } void sub1(int i) {     int j;     j = i - 5;     if (j == 0)          subt();     else          subf(); }

Ok, now let me translate that to the absolute most basic x86 program I can create. It's not going to have frame pointers, all the data will be held in registers (the fastest way), and no stack operations.
Code:
fnc: MOV EAX,1000;1 cycle .ltop: CMP EAX,0 ;1 cycle JE .ldone ;2 cycles CALL sub1 ;2 cycles SUB EAX,1 ;1 cycle JMP .ltop ;1 cycle .ldone RET ;2 cycles sub1: MOV EBX,EAX ;1 cycle SUB EBX,5 ;1 cycle CMP EBX,0 ;1 cycle JE .t ;2 cycles CALL subf ;2 cycles RET ;2 cycles .t CALL subt ;2 cycles RET ;2 cycles
I've gone to the trouble of looking up the instruction cycle times (reference). I used everything as if it were PROC NEAR (which it likely wouldn't be for all code paths) just to keep the numbers from being massive (a CALL is 2 cycles if near, but 26 if far).
The total cycle count for this program is 7,012 to run to completion, which on a 250mhz core would take 0.028ms.

Now, here's the same program for ARM:
Code:
fnc: MOVS R0,#3E8 ; 1 cycle .ltop: BLNE sub1 ; 1 cycle SUBSNE R0,R0,#1; 1 cycle BNE .ltop ; 1 cycle BX LR ; 1 cycle sub1: MOV R1,R0 ; 1 cycle SUBS R1,R1,#5; 1 cycle BLZ subf ; 1 cycle BLNE subt ; 1 cycle BX LR ; 1 cycle
the total cycle count is 3,007, and it will take 0.012ms to complete this program on a 250mhz ARM core. This is 2.3x faster for the exact same program, the reason being, in ARM all instructions take up exactly 1 cycle and every instruction is conditional. I actually used the same instructions as I did in the x86 one, you'll see I added the "S", "Z", and "NE" postfixes onto some instructions. These aren't actually different instructions, they just set bits in the condition field (that all instructions have) that tell it how to operate, with the exception of the S fix, which sets a bit elsewhere in the instruction and is only present on data processing instructions.

The reason why I chose 250mhz? well, that's 1/3 the speed of the original iPhone, so it made a good comparison, and 1/3 value means the numbers aren't impossibly tiny. On the original iphone, these programs would have executed in 0.0093ms and 0.004ms respectively, which isn't even noticeable to the user, but this is a particularly small and useless program (its end result is identical every time unless the status register is being interfered with or has failed). Imagine though that there was a hardware flaw that allowed certain CPUs to speculatively predict and execute code based on a branch prediction result. Assume now that both processors were equally vulnerable to such a bug. You could use this program to determine if the kernel had been compromised, on an intel machine, it would preemptively jump out of the loop since I don't have any sort of frame around it. On an ARM core, however the program would execute normally. This is because of the frequency that the CPSR bits are set. 30% of the instructions executed are supposed to set the status register, meaning that they can't be executed prior to their branches coming up as they would interfere with the logic of the program, whereas on the intel program, only 13% of instructions set those bits.

Let me know what you think, and vote in the poll

RE: [Assembly] ARM or x86? - Blink - 01-18-2018

RISC CPUs are great because of the 1 instruction per cycle thing. It's ridiculous that you can't easily figure out the number of cycles that your program will take on x86 without looking through Intel manuals or analyzing with a separate program. The conditionals are neat too.

However, everyone still uses Intel computers (look at the laptop world), so all the used ASM code will be for x86 or AMD64.

RE: [Assembly] ARM or x86? - phyrrus9 - 01-18-2018

(01-18-2018, 07:10 PM)Ender Wrote: RISC CPUs are great because of the 1 instruction per cycle thing. It's ridiculous that you can't easily figure out the number of cycles that your program will take on x86 without looking through Intel manuals or analyzing with a separate program. The conditionals are neat too.

However, everyone still uses Intel computers (look at the laptop world), so all the used ASM code will be for x86 or AMD64.

That's not entirely true. Look at PowerPC, SPARC, POWER, etc. Mobile phones and tablets almost exclusively use ARM, gaming consoles pretty much use PPC or custom AMD A chips (which are RISC), etc.

RE: [Assembly] ARM or x86? - Blink - 01-18-2018

(01-18-2018, 07:13 PM)phyrrus9 Wrote:
(01-18-2018, 07:10 PM)Ender Wrote: RISC CPUs are great because of the 1 instruction per cycle thing.  It's ridiculous that you can't easily figure out the number of cycles that your program will take on x86 without looking through Intel manuals or analyzing with a separate program.  The conditionals are neat too.

However, everyone still uses Intel computers (look at the laptop world), so all the used ASM code will be for x86 or AMD64.

That's not entirely true. Look at PowerPC, SPARC, POWER, etc. Mobile phones and tablets almost exclusively use ARM, gaming consoles pretty much use PPC or custom AMD A chips (which are RISC), etc.

Specifically laptops and desktops.

RE: [Assembly] ARM or x86? - phyrrus9 - 01-18-2018

(01-18-2018, 07:39 PM)Ender Wrote:
(01-18-2018, 07:13 PM)phyrrus9 Wrote:
(01-18-2018, 07:10 PM)Ender Wrote: RISC CPUs are great because of the 1 instruction per cycle thing.  It's ridiculous that you can't easily figure out the number of cycles that your program will take on x86 without looking through Intel manuals or analyzing with a separate program.  The conditionals are neat too.

However, everyone still uses Intel computers (look at the laptop world), so all the used ASM code will be for x86 or AMD64.

That's not entirely true. Look at PowerPC, SPARC, POWER, etc. Mobile phones and tablets almost exclusively use ARM, gaming consoles pretty much use PPC or custom AMD A chips (which are RISC), etc.

Specifically laptops and desktops.

I've still got a few powermac desktops somewhere and im sure ive got at least one macbook that's RISC

RE: [Assembly] ARM or x86? - Blink - 01-18-2018

(01-18-2018, 07:42 PM)phyrrus9 Wrote:
(01-18-2018, 07:39 PM)Ender Wrote:
(01-18-2018, 07:13 PM)phyrrus9 Wrote: That's not entirely true. Look at PowerPC, SPARC, POWER, etc. Mobile phones and tablets almost exclusively use ARM, gaming consoles pretty much use PPC or custom AMD A chips (which are RISC), etc.

Specifically laptops and desktops.

I've still got a few powermac desktops somewhere and im sure ive got at least one macbook that's RISC

However, most people do not.