Slashdot Mirror
Linux Getting Extensive x86 Assembly Code Refresh
jones_supa writes: A massive x86 assembly code spring cleaning has been done in a pull request that is to end up in Linux 4.1. The developers have tried testing the code on many different x86 boxes, but there's risk of regression when exposing the code to many more systems in the days and weeks ahead. That being said, the list of improvements is excellent. There are over 100 separate cleanups, restructuring changes, speedups and fixes in the x86 system call, IRQ, trap and other entry code, part of a heroic effort to deobfuscate a decade old spaghetti assembly code and its C code dependencies.
Not replaced, you dummy.
Elevated to a new level.
All hope abandon ye who enter here.
Sometimes theory doesn't live up to reality.
Yes, I've hurd that before.
I am Slashdot. Are you Slashdot as well?
That does not fit in with the concepts of 'abstraction' that are fashionable. No 'coder' should really need to understand the actual code the hardware runs. It's all rife with gotos and other icky things. Pointers (physical memory addresses) and stuff get revealed.
No! Mommy! Make the bad hardware go away!
The improved assembly code is what allows the Terminator to be so efficient a killing machine.
Jokes on you. I'm building a VM language in ASM.js and VM bytecode. I get to deal with memory management and multiprocessing issues that are unique to ASM.js. Since the code compiles to opcode which can then be output as "native" ASM.js (which is then mostly compiled to machine code by browsers) or it can run blazing fast on the C VM implementation with its (native) JiT optimizations. Since the platform is meant to be an extremely portable high level and systems level language I'm currently implementing the VM and compiler in its own bytecode, whith the goal of also outputting as x86, ARM, ASM.js, JavaVM bytecode, and Perl6 bytecode.
That means I have to deal with OS level things like spin locks, memory paging, etc. However, it also gives me the chance to radically change the security model such that all code is sandboxed, ran in a VM as bytecode and only compiled and cahed as "native" to the machine / platform / browser if trusted.
Networking abstraction happens to be entire point of the project. Instead of everything being a file, as in UNIX, on my system everything is a network connection. Even Local "native" connections can be seamlessly wrapped as TCP or UDP connections at the OS level, so that IPC is transparent and computing can become distributed without modifying the code. Yes, that means your business can harness the CPU of its visitors to scale availability along with traffic.
Silly single platform devs, still not harnessing every tier of development like plebians. The future is distributed, and you'll get on my level eventually.
That was the most single most hipster post I've read on /. all year.