What are constructive criticisms of both x86 and arm64? Are there technical reasons to prefer assembly on one platform vs the other even if it's just for learning? At the moment I'm leaning towards arm as I have a book here for it and a Pi but really want to know if I'm going to run into problems later and just get an x86 book and stick with my desktop.
There aren't any. They're domain specific that you do when you need to.Folding assembly of any stripe in with high level languages (including C) is another exampe of how stupid /g/ is.
>>103210745Until a big geometric mean of the Apple M4 vs 8500G on openbenchmark can be finalized I feel like ARM "computer" CPUs will probably remain a niche-use thing for people with more money than brains so I doubt it's worth taking too seriously especially since there's a lot of focus in x86 emulation so why work hard twice, ya know?
>>103210745Assembly on ARM and x86 is more or less the same sort of shit.ARM assembly doesn't let you directly access memory operands in anything except dedicated load and store operations. For that reason many people say it is "RISC". However, ARM also has many instructions that let you do more than x86 does. For example, ADD R0, R1, R2 LSL 2 is equivalent to the C statememnt "R0 = R1 + R2 * 4", and equivalent to the x86 code "mov eax, ecx // shl eax, 2 // add eax, ebx". Despite being "RISC", the ARM code only takes 4 bytes, whereas the x86 code takes more than 4 bytes (probably 5 or 6, don't remember exactly).There are also dedicated instructions which can load from a pointer stored in a register and also increment that pointer afterwards, and other neat shit like that. Arm is not a bad instruction set at all DESU. I feel that if you program in assembly it is about on par with x86 in terms of programmer ease, even taking into account the fact that x86 assembly has a lot more resources and documentation to learn from.
I think ARM is probably the easier to get into but if you're approaching assembly for the first time then it is probably better to start with a simpler architecture, like Z80 or 6502.
>>103210745If you can't decide you can try MMIX, it's fun and there's lots of problems.
>>103211126> simpler architectureThe idea that z80 or 6502 is simpler, whilst technically true, is pure retardation. You don't need to know every instruction a cpu has to program the thing. x86 or amd64 are far simpler and easier to program than z80 or 6502 which are an absolute pain, and the skills required to program these ancient cpus are almost entirely useless for modern programming. Its like if you were to learn to mow lawns by starting with scissors.
>>103212034Na, you're just wrong.
>>103210813lea eax, [ebx + ecx*4]
>>103212162Toy example. You can do the same thing with any arithmetic or logical instruction on ARM. I chose a bad example because it's literally the only one that has a 1-instruction x86 equivalent, but you get the idea.
>>103210745x86 is pretty much makes your eyes bleed because of the scars of 50 years of backwards compatibility
>>103210745In both cases the basic instructions are all pretty simple and then they add more instructions for soecialized use cases, then instructions which only run on internal coprocessors/alternate instruction sets like Thumb, x87, AVX, NEON, etc. So really it depends what you want to do. If you want to target a specific device, you'll need to learn it's instruction set, it's quirks, it's memory map, it's syscalls, but you don't need to really memorize much. If you just want to dip your hand into assembly, then just choose whatever is the comfiest setup, if that means using the GNU Assembler to write some x86 that'll run in the context of your normal operating system that's pretty easy to manage. If you want to target some other architecture, then you'll have to bother with cross compilation. So unless you have a serious preference, I'd recommend starting with x86. Although learning an even simpler assembly like for an early microcomputer is also a great option because there are very few instructions.In some ways the most important part about learning assembly isn't learning the assembly language itself, but rather can you take such a low level language like assembly and write it to use higher level concepts.
>>103212215Why do people endlessly repeat this nonsense. Backwards comparability is bad news for anyone needing to implement an x86 processor, or emulator, or anything else of the like. But for programming, the backwards comparability is completely irrelevant.
>>103212034>x86 or amd64 are far simpler and easier to program than z80 or 6502>easiernocoders, everyone.
>>103214618I have programmed, z80, 6502, and x86, and x86 is by far the easiest to program. The 8bit cpus are extreamly limited, the 6502 is especially terrible, it takes so many instructions to do what x86 can do in just one or two.
>>103210745If your desktop runs Linux, you should go with x86 assembly. If it runs Windows, do AArch64 on the Pi instead because Microsoft makes you write a bunch of metadata for every function in assembly and write them in a certain way. Linux lets you do basically whatever you want.>https://learn.microsoft.com/en-us/cpp/build/prolog-and-epilogHow Microsoft makes you write your assembly code.>https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64Binary data Microsoft makes you write for every function.
Programming for a specific architecture is so passé, learn WebAssembly lmao.I'd pick ARM btw.
>>103214908>strlenThat's Worse is Better C brain damage. How many quintillions of cycles were wasted by searching for a 0 byte?
>>103214723Straight up false, nothing forces you to generate unwind info. Also, there are assembler directives that do most of the work for you, you don't have generate raw data structures yourself. Also, linux has similar unwind information you need to generate.
>>103214961Not enough
>>103214908WebAssembly is an abomination. Whoever designed that garbage needs their limbs pulled off.
>>103215174It was designed by C programmers.
>>103215174>just maintain a stack of arguments inside your head brothis is what happens when Rustfags get involved
>>103215195Actual C programmers would not have come up with that worthless high level flow control abomination. It was made by JavaScript programmers.
>>103215135Sure nothing *forces* you to, but if you don't then your program may just crash.https://devblogs.microsoft.com/oldnewthing/20190308-00/?p=101088>there are assembler directivesOnly if you use MASM.>Also, linux has similar unwind information you need to generate.False. Access violations and similar things that windows uses SEH for are instead handled with signals, which don't do any stack unwinding at all and impose no restrictions on your assembly code. You'd only need to make unwind info to support C++ exceptions, and you probably don't.
>>103215195Actually it was made by programmers with decades of experience working on the Java and .NET vms. Wasm has incredible performance for what it does.>>103215209>>103215217The stack and high level control flow massively simplifies the implementation. These were intentional decisions for simplicity and performance.
>>103215256>and impose no restrictions on your assembly code.There are only a few things you are allowed to do in signal handlers.
>>103215273Yeah but it's hard to read. .wasm to .wat conversion should add comments at every line that spell out what each operand operates on
>>103215298Let me rephrase: normal functions do not need to have any unwind information at all or use any retarded prologs/epilogs because the Linux kernel does not unwind the stack. Things that require stack unwinding on Windows use signal handlers on Linux which do impose restrictions on the code inside of them, but none on normal code.
>>103215273The high level flow control makes it terrible to generate code for. Most compilers are based on blocks and jumps, not that high level flow control nonsense.
>>103215386Not if the control flow is still reducible. You can massively simplify the implement if you don't have to worry about irreducible control flow. This has been discussed for years, the decision was made on purpose by LLVM devs to avoid bloating wasmhttps://github.com/WebAssembly/design/issues/796
>>103215256> Only if you use MASMgnu as supports them as well> signalsWindows can do a similar thing to signals using AddVectoredExceptionHandler. Also, far less broken that signals, since its actually possible to use in libraries.
>>103210745x86 is the worst for learning, because it has 45 years of accumulated complexity and seemingly strange design decisions due to backward compatibility.
>>103215695You've got it ass backwards, x86 its actually one of the easiest cpus to the program. The backwards compatibility is totally irrelevant to a programmer.
Motorola 68K
>>103215837It's easy if you restrict yourself to a subset of the instructions. But even in that case, if you're developing an operating system you have to deal with ancient bullshit like real mode and the A20 gate.
>>103210745Why do you want to learn assembly? If it's just for fun you can do whatever you want, I like RiscV. A lot of the knowledge transfers between architectures. If you write in C a lot knowing x86 is useful for optimizing your code. A lot of people will throw code into Godbolt to see what the compiler is going to do.Realistically you aren't going to be writing assembly for anything except SIMD which you'd typically do in C/C++ with intrinsics.If you don't have a goal that requires x86 I'd just do ARM since you have everything. It might be worth mentioning qemu-user as well which lets you run ARM, RiscV, etc. Linux binaries as if they were native binaries.
>>103214700>. The 8bit cpus are extreamly limited,so what? they're not difficult to program for. a limitation does not equal difficulty> x86 is by far the easiestm68k is the easiest by far. >>103215907this chad knowns>>103215837this chud blows.
>>103212034>x86 or amd64 are far simpler and easier to program than z80 or 6502 which are an absolute painHilarious and wrong.
>>103210745The variable width instructions on x86/64 make it a pain to insert breakpoints, and I find the memory-to-memory instructions (despite their power) gay and retarded. However call/ret is nicer than having to manage the link register yourself, altho not pushing the return address of leaf functions is obviously faster on arm64. Having a [dest, src1, src2] format on arm64 instead of x86/64's [dest, src] makes it easier to reason about intermediate values when hand-compiling long expressions, as no registers are clobbered/no information is lost
>>103210745if you actually had a reason to learn it you wouldn't have to ask this question.Find a purpose, make the choices that get you closer to that purpose
>>103218468> a limitation does not equal difficultyYes it does, consider brainfuck for example, by your logic that should be easy to program because really simple.
>start with PDP-11 assembly>can't learn anything else because it's too ugly>Verification not required.
>>103214700>6502 is especially terrible, it takes so many instructions to do what x86 can do in just one or two.That just makes it tedious.
>>103220340>Yes it doesnot how it works at all. limitation does not equal difficulty at all unless you are completely shit at programming.> brainfuck nobody said that was simple. you have made that claim.> by your logicyou don't even understand how any of these chips work. anon was right, you're wrong. again. it's as if you were filtered completely by 8bit cpus and are just seething mad them like they raped your wife or something.>>103221043that anon you're replying doesn't know anything.
>What are constructive criticisms of both x86 and arm64?Constructive criticism means that the function of giving criticism is directed at improving the thing being criticized. There's nothing one can say that isn't already known by Intel and ARM Holdings. They've made the trade-offs they feel most comfortable with.>Are there technical reasons to prefer assembly on one platform vs the other even if it's just for learning?If you are learning an assembly language, learn the one you are most likely to use. Also, know that actually using assembly language is pretty rare. The most practical application for knowing assembly is reverse engineering binaries. Handwriting assembly is generally done when you need to optimize some very CPU-heavy function beyond what a compiler could even do. And in most cases, the hardware that you're going to be targeting is already decided upon.>but really want to know if I'm going to run into problems laterIf you know one assembly language, learning another is not too hard.
>>103223042brainfuck is incredibly simple. It only has 8 instructions. You go could even simpler, there are 1 instruction cpus. They must be the easiest to program, since its just a single instruction to learn.
>>103214323Because mindless parrots aren't people; they're mindless parrots.They repeat some "trusted" figure who hates x86 (most likely because dad got them a cheap Commodore 64C instead of an expensive 386 when they were 7 years old) because they don't really know enough about CPU design, microarchitecture, or even programming, to form their own opinions.Common problem on /g/.
