Ha ha yeah, I’m confused and old 🤤 sorry about that.

That assembly is for a DOS application. It would be more verbose for a modern Linux or Win32 application and probably require a linker script.

But python turns that cute little line up top, into that mess at the bottom.

Technically, not quite. Python is interpreted, so it’s more like “call the print function with this string parameter” gets fed into another program, which calls it’s own functions to make it happen.

I had a course in uni that taught us assembler on z/os. My advisor told me most students fail the course on the first try because it was so tough and my Prof for that course said if any of us managed to get at least a B in the course, he’d write us a rec letter for graduate school. That course was the most difficult and most fun I’ve ever had. I learned how to properly use registers to store my values for calculations, I learned how to use subroutines. Earned myself that B and went on to take the follow up course which was COBOL. You’re not crazy, I yearn to go back to doing low level programming, I’m mostly doing ruby for my job but I think my heart never left assembler hahaha

Ah yes, there was this guy in our tech school class that used to code golf in assembly. Was a crack in math and analytics too, which might explain it somewhat. Well, everyone is different i guess.

Technically assembly is a human-readable, paper-thin abstraction of the machine code. It really only implements one additional feature over raw machine code and that’s labels, which prevents you from having to rewrite jump and goto instructions EVERY TIME you refactor upstream code to have a different number of instructions.

So not strictly the bunch of bits. But very close to it.

I think they meant the other way around, that if you wanted to use it in C/C++, you’d have to either use assembly or some specific SSE construct otherwise the compiler wouldn’t bother.

That probably was the case at one point, but I’d be surprised if it’s still the case. Though maybe that’s part of the reason why the Intel compiler can generate faster code. But I suspect it’s more of a case of better optimization by people who have a better understanding of how it works under the hood, and maybe better utilization of newer instruction set extensions.

SSE has been around for a long time and is present in most (all?) x86 chips these days and I’d be very surprised if gcc and other popular compilers don’t use it effectively today. Some of the other extensions might be different though.

A compiler making assumptions like that about undefined behaviour sounds just like a bug. Maybe the bug is in the spec rather than the compiler, but I can’t think of any time it would be better to optimize that code out entirely because UB is detected rather than just throwing an error or warning and otherwise ignoring the edge cases where the behaviour might break. It sounds like the worst possible option exactly for the reasons listed in that blog.

I recently came across a rust book on how pointers aren’t just ints, because of UB.

fn main() {
    a = &1
    b = &2
    a++
    if a == b {
        *a = 3
        print(b)
    }
}

This may either: not print anything, print 3 or print 2.

Depending on the compiler, since b isn’t changed at all, it might optimize the print for print(2) instead of print(b). Even though everyone can agree that it should either not print anything or 3, but never 2.

I hope you are not argueing that using assembly is an improvement over using C in that regard…

We created the world of monorail 1. Everything exists to bring more people to monorail 1. What is monorail 1? It is a 4 car monorail that takes the shortest possible path back to the start of the station. We have several other attractions at the park such as: The Pit; Memento Mori; Install CSS, but none of them are the main attraction.

Does it have a scientist Batman?

Ah, gotcha. Sorry about the confusion.

That’s no less true than games written in C, or otherwise with few dependencies. Doom is way more portable than RCT precisely because it’s written in C instead of assembly.

you’re not usually directly accessing/working on the hardware

I mean, you are. Sure, there’s a layer of abstraction when doing tasks that require the intervention of the kernel, but you are still dealing with cpu registers and stuff like that. Merely by writing in assembly you are making your software less portable because you are writing for a specific ISA that only a certain family of processors can read, and talking with the kernel through an API or ABI that is specific to the kernel (standards like Posix mitigate the latter part somewhat, but some systems (windows) aren’t Posix compilant).

programmers just not a uniform bunch. not all of them blockchain grifters. fancy that.

Programmers love to rewrite things, but it’s often not a good idea, let alone good for a business. Old code can be ugly because it is covered with horrible leasons and compromises. A rewrite can be the right thing, but it’s not to be taken lightly. It needs to be budgeted for, signed off on and carefully planned. The old system needs to stable enough to continue until the new system can replace it.

That’s when you start introducing modules that have the least impact on the legacy code base. Messaging is a good place to start, but building a new code next to the existing one and slowly refactoring whenever you got time to spare is at least a bearable way to go about it.