Hacker News Reader

Comment by daniellarusso | Hacker News Reader

Good read.

So, dumb question, I had never considered that assembly would have ‘network access’, so are there other ‘higher-level’ systems accessible in assembly?

It just seemed like a different level of abstraction to me.

[edit]

I get it now. I reread the last section and looked over the assembly. ‘Mapping’ to syscalls on the OS.

View on HN

As has already been explained in other answers, ultimately everything comes down to machine code. 0s and 1s. So the closer to the hardware your language is, the _more_ access you actually have. Higher level languages, compilers and operating systems paired with newer hardware features are what _limits_ the access.

If you have a higher level language, that simply has no features to talk to the network and no facilities to insert lower level code, make direct syscalls etc. somehow, then barring exploits, you really can't access the network card.

If you think about it, some parts of the operating system of a computer are actually written in assembly. How are the syscalls themselves implemented etc?

If you want to learn more about what can be done without all these abstractions, then the "toilet paper computer" is awesome if you ask me. We did this in high school comp sci class (with a simulator but the teacher started us off with an actual roll of toilet paper to explain the concept).

https://en.wikipedia.org/wiki/Busy_beaver

There are no dumb questions! In non-VM languages everything is compiled down to assembly (or, more accurately, machine code) since that's ultimately what your CPU executes. Anything else on top of it is just sugar!

Raw machine code does have peripheral access via interrupts and/or the BIOS (which is kind of a "barebones" OS in firmware).

Usually there are several layers of abstraction on top of this (network card drivers, the TCP/IP stack, Unix sockets, etc.) so we don't have to deal with sending raw commands to the network card, but that's just convenience (and those are themselves machine code too).

In non-VM languages everything is compiled down to assembly (or, more accurately, machine code) This is a misconception: Both AOT and JIT compilers can generate directly machine code OR intermediate representations (bytecode, llvm IR) which ultimately reduce to machine code. AOT and JIT simply differ in when the machine code generation is executed. VM are just a special case of JIT that enable hardware agnosticity without fatELF.

The rest of your comment was instructive.

Normally VMs (although strictly speaking doesn't have to be) are not only an abstraction layer but also enforce some form of isolation and memory safety.

Right however full featured VMs allow to escape such safety when needed (for performance and interop with the outside world)

Some systems can be particularly difficult to access through raw machine code. For example with ASLR the addresses of functions and data can move around at runtime, so without using the linker it can be hard to access. Or there are binary obfuscation techniques that are even more thorough with their randomization.

But in the end it all compiles to assembly so everything is potentially accessible there.

All of the higher level systems map down to something very low level, like a syscall or writing to a specific memory address in a specific pattern. The layers of abstraction between the lowest levels and the highest levels can get pretty dizzying, but understanding even a piece of it reveals how fantastic the whole system is.

Reply on news.ycombinator.com