I don’t get why ARM assembly is so much clunkier than it should be. It could’ve been so much more readable and easy to write in if more dev-friendliness was built into the syntax.

Wouldn't Canadians say ARM is RISC...eh?

If ARM is anything like PIC assembly, which I believe is RISC as well, then it is definitely different than the forward facing assembly of x86. Internally x86 is RISC, but to the programmer it is CISC interface.

I remember writing loops in PIC assembler and things would just roll out after a while. Once you get the idea of how it works I think it starts getting more efficient. Though there is probably more code than in CISC assembly.

Why are you writing ARM assembly?

What? ARM assembly is pretty nice, in particular when compared to x86.

@Demolishun "Internally x86 is RISC" how so?
RISC is pretty much the opposite of a CISC like x86

@PonySlaystation They way I understand is a programmer writes CISC for x86. This is then translated inside the chip to microcode which is RISC or RISC like. Supposedly this translation is more efficient? I read this years ago, but now I cannot find the info anymore.

@PonySlaystation Because the external instructions are CISC, but aren't executed like that. Instead, they're split up into RISC micro-ops internally and then executed. x86 are basically RISC CPUs with a frontend to disguise as CISC. There's even an internal micro-op cache for that.

The last actual x86 with real x86 architecture was IIRC the Pentium in the 1990s.

@Fast-Nop that would make sense for performance reasons...
all hail the RISCy god

@PonySlaystation I think one of the main benefits of this is the ability to update microcode on the cpu. I am still unsure how this works. But it sounds like dark cpu magic. I have to imagine a bad update could brick the cpu.

https://intel.com/content/www/...

@Demolishun Yeah, microcode is partly like a lookup table, so you are flexible for future optimizations or to fix "hardware" bugs via software update

@PonySlaystation This is probably why the major cpu manufacturers are all buying FPGA companies.

@Demolishun I am not writing any ARM assembly, my friend @svc64 does. If you want, ask him about the project (I’ll let him know I pinged him so he can join the conversation)

@Fast-Nop absolutely not.

In the transition from ARMv7 to v8, they changed all rX registers to wX registers. *for no reason at all*. It’s the type of confusing shit that they could’ve avoided all together, while making the code (“relatively”) more compatible (I know that all of the instructions are different but hey, now you don’t have to change every reference to 32-bit registers. Less work = more compatibility = more compelling to port the code). They could also make their shit ass thing with multiple source operands with parentheses or something (for example, the ADD or ADC instructions) and have some fancy operator precedence in the compiler.

It’s so unintuitive and so not straightforward compared to x86 to the point that it’s funny.

…not that x86 doesn’t have its OWN issues. I hope x86 will be replace with ARM in the future, but for god’s sake, make the syntax actually approachable before that happens.

@OmerFlame holy shit! I have a friend! <stalker mode initiated> lol

@OmerFlame Ah, I've only been using 32 Bit ARM / Thumb2 in µCs so far. Well, one likely reason is that ARM implementers can optionally implement also ARM32 in ARM64 CPUs, and that means that you can potentially have both the 64 and 32 bit instructions.

Apple's M1 doesn't do that because it would have been more work in an already huge die. That's why they strategically dropped 32 bit support already before with Catalina so that the user frustration from that move wouldn't reflect badly on the M1.

@OmerFlame why not just write a parser that takes in a syntax that's an extension or superset of risc, and outputs regular risc?

Pay me $500 bucks. I'll do it in a week, and deliver a pipeline utility for both linux and windows.

Hell, half the people here could probably do it in a single setting.