/tech/ - Technology

Assembly dying is good. I hate writing it, would hate even more if i had to write it for everything, and it would be less optimized than than the current approach of writing most stuff in C++ and parts you need to in ASM

I plan to learn assembly after rust, seems like it'd be a good debugging skill to read the resulting assembly after compilation.

>>28105
I stare a lot at disassembly, it's completely different from writing it.

>>28105
You don't debug like that. You optimize like that. Learn C after Rust so you learn why Rust is so fucking annoying with memory shit

>>28106
you in fintech? embedded?

>>28107
Embedded.

>>28107
I've always saw optimization as a form of debugging since code using more power than seemingly necessary is unintended behavior, but yeah the difference matters workflow-wise.

>>28103
Based. Fuck ASM and it's 40 billion dialects

I fail to see the problem. we don't need to force ourselves to write in a shitty unergonomic language when hardware is as powerful as it is now, the issue is that the worst abstractions (UNIX and C) are what won the world and everything since then has been a progressively worse series of increased abstractions to try to bandage all the issues with the languages and OSes we can use that are actually supported by hardware. if Smalltalk or Genera had won we wouldn't be having this discussion because they were designed with the intention of creating a well-designed base abstraction that scales efficiently, but because they have inherently higher hardware requirements they weren't as portable and didn't spread as far and fast. we could have a world where every OS is an image/world of objects that the user has complete and immediate access to, but instead we have to write one "high level" language after another to hack together what amounts to a tiny fraction of the power of an OS that is designed with fundamentally good and well thought out abstractions. hell, even Plan 9 is a big step forward in this respect but it still relies on a UNIX worldview of everything being a file, so it would have likely suffered the same issue of not being useful for anyone who doesn't like working with a garbage language like C.

t. smug lisp weenie

>>28125
I'm starting to think the only reason you come to this site is just to advertize Lisp.

>>28127
It's a good reason.

>>28124
>dialects
>40 billion
Moffin' is a trash poster in tech as well huh?

Kinda surprised this is even a thread, the vast majority of programmers these days are solely application developers and obviously there's little reason in 2025 to use assembly for application development, it's just not the right tool for the jobs but it *can* be necessary still for systems programming.

>>28127
I post other things but can't control myself whenever I see any tech thread where bringing up lisp would still be somewhat on topic

>>28125
>relies on a UNIX worldview of everything being a file
Any data can be represented in a hierarchical filesystem with symlinks, even if you need to implement your own filesystem/database structure to get reasonable performance with some structures. I think the process model is a far more crippling aspect of the C/UNIX model of computing. Sensible debugging/error recovery, multithreading and message passing are only a few of the casualties.
>we could have a world where every OS is an image/world of objects that the user has complete and immediate access to
Coming from your blog post about urbit (urbit.org seems to have expired; what a pathetic scam), adopting this model seems to have been one of the few things it got right. While i've continuously failed to get OpenGenera running, i got my hands on a lisp machine manual and data storage seems to be handled similarly to emacs (though defstruct would make obnoxious list structures like in display-buffer-alist superfluous). Except through areas (a more low-level package-like concept controlling allocation/paging) there are no options to discover symbols, so the excellent (or so i've heard) documentation has to bear most of this role. I wonder what's the right approach for storing a large number of disparate symbols: making packages/areas hierachical, reimplementing the hierarchical filesystem (with versioning and something more stateful than inodes mind you) or conceiving of some new tagging system?

>>28132
>Any data can be represented in a hierarchical filesystem with symlinks
>Any data can be represented with holes in a paper card

>we don't need to force ourselves to write in a shitty unergonomic language when hardware is as powerful as it is now
Yeah you're right let's do everything in Python, Lisp, Ruby, Haskell, or another Language With Good Abstractions (tm). If users complain about everything being slow tell them we prioritize abstractions here, and they should just buy more RAM. 500 GORILLION READS ALL OVER THE HEAP TO READ THE VALUE OF AN INTEGER VARIABLE, OR NOTHING!

>>28133
You're missing my point. The unix filesystem api often only gets in the way because of the things it's missing (versioning, standardized locking, atomic writes at an arbitrary offset). At the base level a file is a bag of bytes, so defining abstractions on the data is reasonably fast and a must. Even if seamless "serialization" of data types at the system level is preferable, parsing latency approaches zero for the usual plaintext, config or database file with the only cost being copious reinvention of wheels. Noticeably bad performance usually comes courtesy of the inode structure, something plan9 ditched in favor of the log-structured cwfs.

Uh, yeah. Computers have become more abstract over time. You wouldn't complain about operating systems being a thing since they're an entire system of abstraction themselves. Even assembly languages themselves are an abstraction; machine code is the real barebones type of programming, but assembly is an annoying and pointless level of abstraction considering it's still specific to CPU architecture, and there's no added tidiness.

>>28140
>assembly is an annoying and pointless level of abstraction
Never did low level award

>>28103
all operative systems released ever have some % of assembly because there are things that most compiled languages can't do. sure, you could write a compiled language capable of representing a 100% of OS code, but in practice it is easier to just use llvm or gcc and embed the assembly you can't achieve with the regular compiled language

I think zig 0.5 could do it, but the newer versions can't, because they removed the compile-time parameters to programmatically manipulate the esp and ebp registers for naked subroutines. still, even if you use a compiled language you have to know assembly to understand what you are doing. it is not like user-space software where you already have some base abstractions so you can and should focus on higher level concepts, when you write an OS you are implementing the "abstraction" so you have to be familiar with the "concrete"

>>28141
Strictly speaking, anon is correct that assembly language is still an abstraction, on modern cpus the instructions are implemented in microcode and for both modern and old CPUs an instruction requires decoding and could involve more than one cycle to achieve, because the barebones of computing is still connecting/enabling/disabling pieces of circuitry to achieve different states per cycle that work out to what we'd consider an add or a mov instruction.

>>28150
Strictly speaking anon did not call it an abstraction, but a level of abstraction. But even before you start trying to peek into the internals of a CPU, assembly is different from machine code in some ways, for example it has labels, an abstraction over offsets.

>>28151
Abstractions are only really noticeable when they conflict with some state of the layer below and the logic of the abstraction in question is broken. Most assemblers don't use particularly leaky abstractions, so these cases are few but they do happen.

Consider RISC V, a particularly braindead ISC. Immediate instructions encode on parameter in the instruction itself, that has a size of 16 bits. Now what happens if you specify an integer larger than 2^16-1 for such an opcode and feed it to an assembler. Does it throw an error, warn you about it, inform the programmer in literally any way? No it just happily takes the modulo and makes you wonder why your ANDI instruction produced a zero. The shift instructions also only take unsigned arguments, contrary to every sane ISC, and silently coerces the second source register to unsigned.