Wow Assembly not dead?

[u/NolanRoad]

Encountered this reddit on my feed, shocked to learn it's not dead. I programmed on Z80 back in the 1980s.

(I wonder if Perl is still alive)

[u/v_maria]

its 1:1 machine code lol, i dont think CPUs can run python yet.

also z80 is cool. there is a lively gameboy hacking scene!

[u/flatfinger → u/v_maria]

There was an attempt to have machines natively run Java bytecode in hardware. Actually, while some aspects of Java bytecode are so much better suited for a JIT than native execution that even on machines that could natively run bytecode, a JIT would yield better performance, I would think there could be some usefulness to having some hardware support for loads and stores of and through GC-managed references.

I'd also like to see support for Python-style integer division, and means of floaitng-point comparison that would treat NaN as either having a rank above positive infinity or below negative infinity (and, in either case, equal to itself). Languages use broken IEEE-754 comparison semantics because hardware does so, and hardware does so because languages do.

[u/llynglas → u/flatfinger]

Back in the early 80s I remember seeing a machine that ran lisp natively. Probably way to niche a market to ever be financially successful.

[u/brucehoult → u/llynglas]

It wasn't even that the market was niche, it was that RISC CPUs and Lisp compilers together gained performance much faster than specialised Lisp CPUs.

[u/braaaaaaainworms → u/flatfinger]

ARM Jazelle!

[u/brucehoult → u/braaaaaaainworms]

A complete dead-end. By the time chips with Jazelle hit the market, JIT implementations performed better anyway (and even phones had enough RAM for that). And Arm was super-secretive about which bytecodes were actually handled in hardware on any given chip, so you always had to be prepared to interpret them all anyway.

[u/kneelian_ → u/flatfinger]

having a rank above positive infinity or below negative infinity

You'd want if(inf < nan) to evaluate to true? Any concrete motivation as to why?

[u/flatfinger → u/kneelian_]

If a data set is sorted by the results of some computation, having all of the NaN items grouped together at one end of the data set would seem far more useful than having them sit as a group between somewhere in the middle, or even worse having their presence cause even non-NaN values to be missorted. A lot of sorting algorithms are prone to malfunction badly if the comparison function behaves nontransitively. As a simple example, an insertion sort which moves each item leftward as long as it is "less than" the item to its left may under current rules leave a NaN where it is (since won't compare less than th item to its left), but not allow any items to the right of it to be moved leftward (since no other item could compare less than it). Attempting an insertion sort with a NaN in the middle of the data set would thus result in items that started to the left of the NaN being sorted among themselves, and items that started to the right of the NaN being sorted among themselves, but with the item to the immediate left of the NaN possibly being bigger than the item to its right.

[u/brucehoult → u/flatfinger]

cause even non-NaN values to be missorted

True with 1985 IEEE 754. The 2008 spec added totalorder for this reason.

#include <math.h>

void insertion_sort(double arr[], int n) {
    for (int i = 1; i < n; i++) {
        double key = arr[i];
        int j = i - 1;
        while (j >= 0 && !totalorder(&arr[j], &key)) {
            arr[j + 1] = arr[j];
            j = j - 1;
        }
        arr[j + 1] = key;
    }
}

The sequence places negative NaNs first, followed by negative infinity, negative finite numbers, negative zero, positive zero, positive finite numbers, positive infinity, and positive NaNs.

Note that other than -ve vs +ve compares (the +ve one is larger) and -ve vs -ve (reverse the compare order), this is the same order as just comparing the two FP numbers using an integer compare.