Why assembly is so overrated?

Why assembly is so overrated?
It's not that hard, everyone can do a kernel in assembly
arjunsreedharan.org/post/82710718100/kernel-101-lets-write-a-kernel

It just works

Attached: aid39743-v4-728px-Start-Programming-in-Assembly-Step-3-Version-3.jpg (728x551, 66K)

It's not overrated. Every device that possesses a cpu uses assembly.

I think op meant that assembly's difficulty was overrated, which is true, people talk like it's some impossible shit nowadays, it's impressive how out of touch developers are with how their software actually runs.

>everyone can do a kernel
That's a bit far fetched.

You JUST figured out that low level languages are a masturbatory tool for brainlets who can't understand software architecture? Hence big push for "minimalism", they're literally confused by anything that has more than 2 abstraction layers.

VHDL,Verilog > ASM

>using grub instead of rolling out your own chainloader
Pig disgusting, OP, and fucking lazy.

Attached: Screenshot_2018-06-28_09-35-55.png (750x1294, 200K)

this, GRUB is such a bloated piece of trash.

Simplest kernel isn't complicated program and 90% of it is boilerplate from specifications that can only be done in assembly/machine code because it's architecture-specific feature of CPU and can only be done in one way. It's not even a programming challenge.

>Not using assembly for optimizations
>Not using assembly for embedded applications
Codemonkey brainlet detected

>doing by-hand "optimizations"
>using asm for embedded
It hurts itself in confusion.

>Thinking he can optimise his code better than a compiler written for the job
>Wasting time writing ASM for a system that's already been designed to have C compiled for it

Just remember, when you're at the lab wasting another evening doing something someone else has already done, Tyrone's at your house doing something you've already done :^)

It's good for simple things.I only use it to make software that controls rfics.

>Thinking he can optimise his code better than a compiler written for the job
I'm not saying you should do it, but usually it's not that hard to be faster than the compiler.
Why do you think people used to write games in assembly a few decades ago?

>every device that possesses a cpu uses assembly
That would be machine code, not assembly.

>Decades
Because the field of compiler development hadn't been pushed as far.

You clearly never worked on embedded systems. I'm not saying writing all the code in asm. I'm saying parts that need to be optimized need to be written in asm as a failsafe.

>doing something someone else has already done
Why are you saying things someone else has already said?
Why are you thinking thoughts someone else has already thought?
Why are you pressing keys someone else has already pressed?
Why are you existing if someone else has already done that?

I'm not defending the retard you're responding to but your argument isn't much better.

Even with more recent compilers, C is shit on older computers/consoles

And yet compilers still suck at vectorization.

intrinsics > large assembly methods

Register allocation shouldn't be done manually.

You can't do everything with intrinsics.

Attached: 1529911625936.jpg (459x643, 11K)

You can write your own intrinsics. gcc's extended asm syntax helps to not worry about register allocation.

>Not writing in machine code

Machine code>ASM

You still can't use anything hyper specific like control registers.
If you're going to write a bootsector or a kernel you don't have an option, you're going to have to use some form of assembly.

Attached: 1521529182313.gif (300x424, 2.56M)

can't write "mashine code" on x86

> I have no clue how VHDL works, the post
You're supposed to write Assembly code for your processor you described in VHDL

Why not? Not him and I've only programmed with opcodes on a 6510 cpu (never tried to do that with x86), but I'm sure it's possible.

Based

Attached: 1507512311613.jpg (645x729, 26K)

What the heck is this?
>#Creates an app
>call make_app

>What the heck is this?
It's my autism detector.