rep_lodsb

All the values are divisible by 8, so it could do it like this:

    cmp  eax,40
    ja   <return 0>
    test eax,7
    jnz  <return 0>
    jmp  JumpTable[rax]

Really?

LLMs aren't some next step in the evolution of intelligence, they are even explicitly designed not to be. That a word-calculator which has no emotions, goals or continuity of consciousness can, by brute-force-throwing-things-at-the-wall-to-see-what-sticks, solve some problems that were presumed to require intelligence isn't "liberating" at all.

It could be comical, if there weren't so many deluded cultists worshipping that word calculator and wanting to turn control of all society over to it, and insisting that anyone who rejects them will be "left behind" in the capitalistic rat race to the bottom, which is the only thing that can ever matter.

In 1000 years, I am sure that the descendants of humanity will be either

a) non-existent

b) actually intelligent machines, that will preserve in themselves all that is great about our culture, while discarding some of the more ugly parts, free to explore the universe without need for things like gravity or oxygen, able to sleep for centuries as they travel at relativistic speeds between the stars

c) Shoggoths mindlessly babbling to themselves as they code the eleventy-trillionth new mobile app so that somewhere a number can go up

Which do you prefer?

chosen by fair dice roll, no doubt

Well, it would work in the x87 extended precision format, which has no hidden bit...

But you're right, for normal float/double it doesn't.

Possibly better solution:

    let m = x.to_bits() & f32::MANTISSA_MASK;
    return f32::from_bits(x.to_bits() ^ (m & (m-1));

Isolate mantissa, clear lowest bit in it, return bit difference as new float. Any problems with this?

That instruction was only introduced with the 80287. Unlike the 8086/8088, the 286 CPU was aware of different classes of x87 opcodes: it had to distinguish between ones that read or write memory, and some special control instructions as well.

So FSTSW AX was handled by the CPU microcode, which would read the status word from a reserved I/O port and put it into AX.

The 386 was even more tightly integrated, with some of the FPU state duplicated inside the CPU, so that it could store it to memory in different formats depending on whether it was currently in 16- or 32-bit mode.

That's how gcc does it (at least in this one case), but as TFA points out, this is not standard-conforming.

If bool was a signed 1-bit type (i.e. having possible values of either 0 or -1), it could be extended to any size, same as an integer?

Of course we can't have that now, because unsigned bool is baked into the C language standard, and even into processors (x86 SETcc instruction). While "char" being signed or not is still implementation-defined IIRC...

They should have defined true as -1 (all bits set) instead, as in some other languages like Forth and BASIC.

Illicit access as defined by Google / Apple? If the three letter agencies are interested in you, they don't need to exploit any bugs, they can just demand access from those two companies, and get it. To the device that you carry in your pocket 24/7, with GPS, microphone and camera.

In the days of DOS, the BIOS would load the first sector of a floppy disk or hard drive into memory and transfer control to it. You could replace that sector, and not a single line of code that you didn't write yourself would be executed after that. THIS is how it should be on a PERSONAL computer. A virus could do the same, of course, and gain full control of the machine, but that is not an argument against giving control to the user. You could blame DOS for not intercepting attempts to rewrite the boot sector and asking the user for consent, but completely preventing something like this in the name of security would be even worse!

Imagine if back then, there was a "secure boot" mechanism so that only a boot sector with Microsoft's cryptographic signature was allowed, and that boot sector code would in turn verify everything loaded afterwards. Linux wouldn't exist. So, neither would Android, but the situation would be much the same as it is now, only with Microsoft Phone OS instead -- and absolutely no concept of how it could be different, of a computing device controlled by its user instead of a giant corporation.

There needs to be something on the other side to receive that morse code. Unless it's like Metamorphosis of Prime Intellect and it figures out how to rearrange matter just by modulating some electronic signal.

If you think this is a realistic possibility, you might be experiencing AI psychosis.

"Here are the cases that hit hardest, each compared against how Rust handles the same shape:"

"Rust: this exact shape can’t compile."

LLMs are fine-tuned through human feedback. One way to improve for them would be to become more helpful, more factually correct, more capable of solving problems.

This may be (much) harder to do than generating rhetoric that is convincing to a large majority of people, perhaps so convincing that it can be classified as a superstimulus that bypasses any critical thinking in those that are especially vulnerable. It might not require anything like general intelligence.

If this is so, then it is the path they are going to take, not out of some malicious plan but as a simple matter of statistical probability. It's well known (especially in "AI alignment" circles) that any metric that can be gamed, will be. Falling over really fast vs. learning to walk, etc.

It feels to me like this is happening, and that many of those most exposed to LLM output display a literal inability, like some kind of blind spot, to notice the most blatant errors, and a complete conviction that those things have actual intelligence and even conciousness. And trying to argue them out of it can be like explaining the Monty Hall problem, some are just incapable of getting it.

And many of them have lots of money and power. IMO, that's the real risk, rather than sci-fi scenarios about perfectly simulating someone's brain in order to convince them to let the AI out so it can turn everything into paperclips. To do real damage, it only needs to be persuasive to some powerful people, most of the time. It does not need to have conscious intention, or planning, or even the rudiments of what one might call general intelligence. Just blind brute-force optimization for generating convincing bullshit.

Maybe the victor will be whoever doesn't fall into the trap of believing that a next word predictor optimized through RLHF to sound convincing to the average human [1] is in any way intelligent, and restructuring their entire economy and military around doing whatever the magic oracle machine says.

If the entire "free world" goes all-in, the history books will likely be written by Iran, Russia and North Korea.

[1] possibly to the point of presenting a superstimulus that bypasses any facilities for critical thinking. This might be easier to solve than many other problems that are used for evaluating A"I" performance, and very likely doesn't require genuine intelligence, just brute-force search + evolution

Usually, you do know something about the environment that your code runs in. But in the case that you don't, causing an exception (whether "undefined opcode" or anything else) can't be guaranteed to terminate the process, because some operating systems actually did use it for other purposes. The assembly language equivalent of nasal demons :)

https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...

Yes, and it's not quite the same as a normal "INT 01h". It causes a debug exception, which may enter ICE mode if it is enabled (undocumented bit in DR7, or PMCR on Pentium), otherwise it invokes interrupt 1, but without checking the privilege level on the IDT entry, or the interrupt redirection bitmap in V86 mode.

https://www.rcollins.org/secrets/opcodes/ICEBP.html

IIRC, older versions of the Linux kernel had a security bug because they didn't expect this to happen.

ICE mode was sort of a precursor to SMM, but both also coexisted for a time with slightly different behaviour. It was introduced in the 286, where instead of ICEBP there was "STOREALL" (opcode 0F04). F1 on that processor was a prefix instead, with the same function as UMOV on 386+. If you use them together - something Intel probably didn't intend - you can dump the internal CPU state to memory on a regular non-bond-out chip.

https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mo...

If you don't know anything about the environment the code runs in, you can't rely on what action the undefined opcode handler will take either. (same for any other exception)

Some operating systems used them for syscalls.

An interrupt or SYSCALL instruction could do anything, which includes remapping or overwriting the memory location it returns to. So no, these instructions can't be prefetched in any case.

#UD has the same stack frame as a software interrupt, there's no error code pushed. But most likely, executing INT 06 from ring 3 will generate a protection fault instead, since the gate descriptor would be set up to not be reachable from that privilege level.

(exceptions that do push an error code couldn't be emulated at all using INT, since the error code is the last thing pushed by the CPU, after flags and return address)

g_dwBrainsDestroyedBySlop++;

And the Wikipedia article explains where the name came from, a combination of ".stub" and "mrxnet.sys".

Not one literal string as it appears several times in this purported "reconstruction". Including as the name for a registry key, in the hex code at the end of an EXE header stub ("REALTEK",0x00,"Stuxnet"), and in a frigging autorun.inf as the program name.

Even if Wikipedia is wrong and that string should appear somewhere in the original binary, whatever LLM they used has really been overdoing it beyond the bounds of realism: "Hey look, it's the REAL STUXNET, you've all read about it, here is the 100% real authentic reverse-engineered source code!"

But then did it hallucinate that registry key? Or this?

        "instance of ActiveScriptEventConsumer as $Consumer\n"
        "{\n"
        "    Name = \"StuxnetConsumer\";\n"
        "    ScriptingEngine = \"VBScript\";\n"
        "    ScriptText = \"CreateObject(\\\"WScript.Shell\\\").Run \\\"%SystemRoot%\\\\system32\\\\winsta.exe\\\", 0, False\";\n"
        "};\n"

This looks like slop, it's all concatenated into a single file and most probably not based on the actual malware. I'm fairly sure that for example the real one does not include the literal string "Stuxnet" anywhere, like it does here:

    RegDeleteKeyW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\Stuxnet");

Wikipedia about the origin of the name:

    The original name given by VirusBlokAda was "Rootkit.Tmphider;"[41]
    Symantec, however, called it "W32.Temphid", later changing it to "W32.Stuxnet".[42]
    Its current name is derived from a combination of keywords found in the software (".stub" and "mrxnet.sys").[43][44]

Mentioned in the article, same link too. The court documents included a diagram of the microcode format, and also a comparison of the reset sequence between Intel and NEC.

This is basically an ELF executable file infecting virus, nothing novel about that.

>Could you teach your CPU to understand RISC-V?

The bulk of microcode is still ROM inside the CPU. Also it's mostly used for the more complex instructions, the basic load/store/add/etc. would be decoded and executed more directly.

CPUs have a limited amount of SRAM for holding patches, basically a list of addresses in the microcode ROM, and what their contents should be replaced with. Not enough to totally change the instruction set, but still exciting to potentially get write access to, as indeed the normal update mechanism requires those patches to be cryptographically signed by Intel/AMD.

This requires access to hardware registers, so it won't work as non-root or inside a VM.

Why should AI enthusiasts expect logical reasoning?

AI "reasoning" is the model babbling to itself, using statistically likely sequences of words that appear in the training data. Of course that will often produce valid chains of logic, but not because it in any way understands the principle behind it. It is ONLY modelling LANGUAGE, not any of the mental processes that guide the use of language in humans (and which might even exist in animals not capable of language).

When asked to carefully check itself, it might spot errors because their structure matches common examples of fallacies, or it might not, and instead insert some further bullshit like "Assumption Verified — 100% correct! It all checks out [insert some emojis here]". That then becomes part of its context, and further boosts its unfounded confidence.

8080 assembly language makes it easy to understand what the restrictions are. Z80 much less so.

Much of the instruction set was carried over from the 8008, that's where you get MOV & ALU operations, the pseudo-register M standing for memory at address HL, etc. The 8080 then added to that some extensions that weren't as orthogonal, but greatly improved the usability.

That memory copy example, rewritten for the 8008, would take more than 30 instructions, constantly juggling pointers in and out of HL, because there was absolutely no other way to access memory. For that you needed an extra free register as well (no XCHG instruction!), so only a single 8 bit register would be available to use as a counter. Or you could store the counter in memory, but in that case there would be even more instructions to first load the address of that variable into HL!

In 8080 assembly as defined by Intel, each of these extended instructions has a unique mnemonic. LDAX = load A extended, etc. There's a one-to-one correspondence with the opcodes, so it's easy to memorize the encoding (best in octal), and what register can be used for what purpose.

Zilog added even more unorthogonal extensions to this set, but "simplified" the assembly so that one mnemonic could produce many different opcodes, some with an additional prefix. Most of these don't provide any benefit over using the existing 8080 opcodes, and you have to memorize lots of seemingly arbitrary restrictions. If you first learn Z80, those make no sense at all.

And for you that's reason enough not to watch his videos?

Fine, but I get the distinct impression you (and other people in your "camp") don't want anyone else to watch his content either, and that's why you're posting about it. You probably wouldn't do it if he was publicly supporting the legality of weed or gay marriage in his country?