Message from @M4Gunner
Discord ID: 429471747280994304
About 20% of the class couldn't make it fit in the 256 bytes.
what book did they give you for assembly
assembly is cancer
^you probly like java
^likes js
Another we had to do was long division. Actually, now that I'm thinking about it, the 4-bit instructions one was to program long division. The architecture didn't have division. The normalization one was on an 8-bit instructions architecture. Same 256 bytes limit for both.
well you've already said assembly is cancer twice. yet your computer needs it to run, js or no?
We didn't get any book, the course was on computer architectures. We went through the design of various didactic architectures, then at the end some MIPS and IA-32.
if i wanna play with ARM i should buy an rPi??
There are plenty of ARM devices.
yeah but its mainstream, deployable, versatile, so it's a good starting point?
yee
By all means, learn some assembly, it'll do you some good. But you don't really write programs in assembly; at least not if you want to finish coding it any time soon.
Mainstream? Go for x86-64.
You should know what compiled code looks like, specially if you want to have any hope of debugging code properly.
Say, what a function call looks like.
What an array access looks like.
What a C string operation looks like.
What an `if` or a `for` look like.
But you don't really write any significant code in assembly. We have compilers for that; at which point the architecture is irrelevant - as long as the language is supported by the hardware vendor.
Dude, even NES games were made with compilers (or pseudo-compilers) back then.
Embedded devices these days have plenty of RAM and CPU.
When you program something for a raspberry pi, you do it in a high level language.
well what do arm asm dudes get paid for?
Usually people just run Linux on a raspberry pi, and thus they can use any language that runs on Linux + ARM.
also, as far as my reasearch i was under the impression that all or most 8/16bit console games were coded in assembly. But as I'm learning I see it's all about sweettalking the Assembler with macros to let you write human-readable code
What would often happen is, some essential routines would be written in ASM, and they would be glued with an "almost high-level language."
sure like Doom used asm just for the column and span rendering
Back then compilers were bad at optimizing.
But they were perfectly fine for just calling routines that were written by hand in assembly.
I don't want to say that you don't need assembly, it's just that it's not for software development; you need to understand it if you're doing specific tasks for optimizations, for instance.
But you don't develop anything non-trivial in asm.
Takes too much time, and the compiler does a better job than you overall.
Even if you think the compiler can only do 90% of the optimizations you can do by hand... the compiler can work at 90% efficiency for the whole program, and never get tired, never make a mistake.
So even people that enjoy working in assembly, they first profile the program to know the hotspots, and only optimize by hand the few parts that will actually make a difference.
Even then, just because you think your code is better than the compiler's, doesn't mean it's actually faster.
I dodnt think i'd ever be good enough at it to compete with the compiler
This website is good, if you want to quickly play around with assembly output from various compilers.
Simple test with ARM assembly.