Hacker News Reader

Comment by zgs | Hacker News Reader

Assembly is faster and safer than rust. Rust is a fad it will fad.

Yeah, the language that:

- has been around stable for over 6 years and was already somewhat popular years before that

- is the first real contender to C in the Linux kernel, with support from its BDFL and a lot of work going on, and well those devs know a bit more of pain points in complex systems that need to go fast.

- is used in of the major Browsers while the most popular one is contemplating starting to use it

- allows refactoring and cleaning up code so nicely, it's just marvellous if one actually worked on big code bases previously to rust, as either one had ten static checkers and three times the amount of CI pipelines as required bolted on, or just risk quite a bit every time something was touched.

- deep and mature integration of tests and docs and doc-test (those are damn nice)

- want me to continue? I got a few more points

surely is a fad ;-)

Look, you do not need to use Rust if you do not want too, but living in denial about that Rust has seen a good rate of adoption and that it also has its uses as valid Language to do stuff nowadays, is just not a good thing to do mentally nor socially.

What measure of safety has assembly basically ever win?

There's no undefined behaviour in assembly language.

As Computer Engineer: oh well, do I have bad news for you ;-)

Quite a few processors have some undefined behavior, some instructions flags are just not specified, and no not just "this is reserved and must be zero", that would be Ok.

The result of the `bsf` or `bsr` instructions on the 0 value

And please, don't look too much at the FPU either or it may do some random stuff and jump at you.

Indeed, best to avoid any eye contact with the FPU at all.

Only if you define "undefined behavior" as in a very constraint sense (as in "the language specification doesn't specify the behavior").

But CPU architectures also have undefined behavior. ARM for example calls these "UNPREDICTABLE" and "CONSTRAINED UNPREDICTABLE". Have a at the Armv8 architecture reference and grep for those. Lot's of ways to write programs in pure assembly with undefined behavior too!

x86, 6502 and Z80 etc all have undefined / unpredictable behavior too.

6502 is extra fun, because it has "unstable" instructions, whose result would be dependent on specific chip, temperature, and other factors. I can't find the article that dissected some of them anymore, but as I recall it was because of stuff like an (internal) bus conflict with multiple drivers enabled (EDIT: close, but it's even wilder than that).

EDIT: Thanks to IcePic's answer, I found it here: https://web.archive.org/web/20210405071521/http://visual6502...

There is a writeup in PDF here https://csdb.dk/release/?id=198357 about what actually happens on all the unimplemented instructions that still "run" parts of the CPU, some with decent results, and some with less.

And for the last part of your sentence, it depends on what address you run some of the instructions from, since they take a byte out of that in account when doing the weird operations, so some bad instructions can be used, if you are running from $fe00 - $feff because it takes the high byte ($fe), adds one to it, then ands something else with it and lastly produces a result that leads to a usable instruction, but only if the and is with $FF so it doesn't drop bits on you. =)

Lots of weird/fun reading there.

Thanks, but I meant something even more unpredictable, which is hinted at in your document: "ANE [...] is chip- and/or temperature dependent" and "can not be reproduced in visual6502, which hints on it being some analogue side effect that the simulation does not cover".

It's a shame that I cannot find the other article, because I remember that the author actually had looked at the individual transistors, and figured out the bus conflict or whatever it was, which pretty exactly described what happened, and maybe even why some bits would be more "weak" than others.

EDIT: Oh, hah! Your PDF actually links to it in the same section. The wiki seems currently down, but here's an archive.org link of the page that describes the unstable opcode in great detail. So thanks a lot! https://web.archive.org/web/20210405071521/http://visual6502...

I invite you to search the ARM reference manual (the so called "ARM ARM") for the terms UNKNOWN and UNPREDICTABLE. There is also actually UNDEFINED, but in the context of ARM it means that a specific exception happens, so it's pretty much the most PREDICTABLE of the bunch.

The old VLSI Technology Inc (later Philips, now NXP) reference manuals for one of the first ARM processors (the one used in the Acorn Archimedes 305, 310) mentioned that the algorithm used for cache eviction was not something relatively predictable like LIFO or FIFO but essentially random. Which in theory means that if you were 'unlucky' then your program would run slower than for a luckier person etc.

Ha. Though if you're seeing a persistent difference over time, thousands and millions of evictions, your luck is already so immaculately bad that you should expect the power to go out every time you try to run a program.

also ++C is faster

You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence.

Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.

Optimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.

Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.

With complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference

a++; means do nothing then increment a, ++a means increment a then do nothing, what should be the difference? (Of course you can define operator++ to format the hard drive. )

If you have a single-pass compiler (for speed) then it will not know on pass #2 that the old value is to be used for something or not and can drop it.

In a single-pass run, you must generate code to keep the previous value in case the line actually was foo = ++a; or foo = a++; so that foo gets the pre-inc or post-inc value.

The small part that creates the code for the small "a++" part of the line will then produce a dead store of the pre-inc value, and no 2nd pass will remove it.

Allow me introduce operator overloading, where I have suddenly defined a ++ operator on my god object that contains a 50MB pool. This operator increments a single field in it, and I really need it because I do it so often.

++godobject will simply increment that value.

godobject++ will make a copy of that object, returning it to you along with allocating another 50MB pool, purely to increment the value.

That's what I meant with operator++ being redefined to do anything.

but when you write generic algorithms (as you should), you don't know beforehand with which "operator++" your a will be called. So you have to go for the one which will give the best performance.

> a++; means do nothing

only if a is a very simple thing. plenty of "advanced" containers actually do things ; in the "a++" case they have to save the previous state to return a copy, in the "++a" case they don't. If your iterator for instance contains a std::vector<int> to maintain some internal state for a multidimensional dynamic matrix, then in one case you'll get a simple increment, in the other a whole dynamic allocation / free which may be optimized out by the compiler in release mode and definitely won't in debug mode

That is increment a part, for whatever is being defined as incrementing for this class. If you define different things for post and pre increment they will cost differently, sure. If the compiler decides to do more than what I told to, it will be longer. But will a++ always cost more than ++a?

> If you define different things for post and pre increment

They are defined as different things. One returns the current value and increments, the second increments the current value and returns it. In the first case you have to cache the previous value, in the second you don't. If your operators don't do that they are bugged and wrong.

Only C++ programmers will appreciate this joke.

Thank you for laughter.

Reply on news.ycombinator.com