rep_lodsb

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?

16-color EGA and VGA had separate bitplanes, so writing 4 monochrome images would take the same time as a single one in color.

That's a limitation of the Turbo C library, as the comment says. DOS memory allocation functions take the size in 16-byte "paragraphs", and return a segment, with the allocated memory starting at offset zero in that segment.

A lot of that is just bloat that you wouldn't have had back then. But it could still be handled by an 8086, not by storing the raw HTML in memory at all, but parsing it as it loads. Each DOM node would be its own object with child pointers, with attributes and names all converted into binary numbers of (at most) 32 bits each.

64K of actual text content in a single node could be reached in some documents, but it's not that small, more than a chapter of a typical book.

What was always a problem for segmented memory was graphics, at least if you wanted higher resolution than 320x200 at 256 colors. But you could have a segment pointer to each row of pixels instead of an entire image, as long as it would still fit within 1 MB (16 MB in the 286 protected mode).

Well, one indication is the value loaded into EDX on reset:

    9B5 BIST1  -> TMPD    0x0303         PASS2
    9B6 SIGMA  -> EDX
    9B7 BIST2  -> TMPE    TMPD           XOR
    9B8 SIGMA             0x3ddc0c2c     XOR
    9B9 SIGMA  -> EAX     BOOTUP_JUMP    JFPUOK

0x303 = family 3, model 0, stepping id 3.

Maybe websites should work without loading megabytes of scripts from third-party servers? I think that should be disabled unless you opt-in.

Also browsers by default using a blocklist from some company, and showing a giant scary warning and contacting their server when the user deliberately navigates to an URL that is on that list. That should be opt-in as well, rather than something that just happens and is considered acceptable.

Something like uMatrix should be built right into the browser, and the fact that this isn't the case really says it all about how it's not the "user agent" anymore. It's the one extension that's absolutely essential IMO -- no third-party connections at all by default, yes it breaks a lot of sites, but then you should ask yourself if the content was really worth reading in the first place!

Besides the blocking, being able to see at the click of a button what kind of crap most sites want to load is really eye opening. And they would do so completely silently if you're using a "normie" browser created or financially supported by the largest advertising company in the world.

Instead the mainstream gets "security features" like Safe Browsing, where it connects to a Google server every day without most people's consent or even knowledge, downloading a list of hashes of "bad stuff" to block. Like open source software to download videos from YouTube (yt-dlp), which it flags as malware. Of course the tinfoil hat conspiracy theory that it's also sending every URL you visit to their server isn't true -- only the ones that match a hash, "to check for false positives". It's easy to see how this mechanism could be abused to log who is visiting particular URLs of interest, without alerting the user to it happening. As far as I see it, you would just have to trust them when they super-double-pinky-swear they would never do this. And of course the TLAs wouldn't allow them to disclose it if something like this happened on their orders.

Slight correction, the correct offset is 7, and DAA only adds 6. But the trick is also adding the carry bit. This works on the 6502 in decimal mode too, e.g. https://news.ycombinator.com/item?id=6342286

On the Z80 and 8086, the code can be made one byte shorter by taking advantage of adjust-after-subtraction, which the 8080 didn't have (and on 6502 worked differently):

    CP   10      / CMP  AL,10      ;set carry if valid decimal digit
    SBC  A,69H   / SBB  AL,69H     ;0..9 => 96h..9Fh (auxC=1), 10..15 => A1h..A6h (auxC=0)
    DAA          / DAS             ;subtract 66h if auxC set, 60h if clear

I know this comment will get ignored by the true believers, and likely pasted directly into Claude by the author in order to "further improve" the code, but here's some small excerpts from the terminal emulator (glass.asm, 19360 lines, 555 KiB):

    cmp dword [rax], 'XAUT'
    jne .rxa_next
    cmp dword [rax+4], 'HORI'
    jne .rxa_next
    cmp word [rax+8], 'TY'
    jne .rxa_next
    cmp byte [rax+10], '='
    jne .rxa_next
    ; Found XAUTHORITY=path

Okay, this is setup code that only runs once at startup - but that would be a reason to optimize it for size and/or readability! REPE CMPSB exists, and may not be the fastest, but certainly the most compact and idiomatic way to compare strings. Or write a subroutine to do it!

This pattern is used everywhere for copying or comparing strings, this was just one example of it.

There's a state variable that's used to keep track of whether the input is text to be displayed or part of a control sequence. It's a full 64 bits, probably not because we need 18 quintillion states? Here's how it is evaluated:

    ; Dispatch based on state
    mov rcx, [vt_state]
    cmp rcx, VT_ESC
    je .vtp_esc
    cmp rcx, VT_CSI
    je .vtp_csi
    cmp rcx, VT_CSI_PARAM
    ...

In total, there are 7 compares + conditional jumps, one after another. Compilers would generate a jump table for this, and a better option in assembly might be to make vt_state a pointer to the label we want to go to. Branch predictors nowadays can handle indirect jumps, and may actually have more trouble with such tightly clustered conditionals as seen in this code.

This code is on the "slow" path, there's a faster one for 7-bit ASCII outside of control sequences, with a lengthy comment by Claude at the top on how it optimized this. Even this one starts with a bunch of conditionals though:

    cmp qword [vt_state], 0            ; VT_NORMAL == 0
    jne .vtp_loop_slow
    cmp dword [utf8_remaining], 0
    jne .vtp_loop_slow
    cmp byte [pending_wrap], 0
    jne .vtp_loop_slow

These could likely all be condensed into a single test or indirect jump via the state variable, by introducing just a few more states for UTF-8 decoding and wrap. Following this, here's a "useless use of TEST" (the subtraction already set the flags):

    mov rbx, [grid_cols]
    sub rbx, [cursor_col]              ; rbx = cells left on this row
    test rbx, rbx
    jle .vtp_loop_slow                 ; no room (or already past)

This also again shows the compulsive use of 64-bit registers and variables for values that should never be this big. It's not the "natural" data size on x86-64 at all, every such instruction requires an extra prefix byte.

I freely confess that I'm a "Luddite", and was explicitly looking for bad (and obviously so) code, but this took me just a few minutes of scrolling through the nearly 20K lines in this file, so it should be somewhat representative of the whole.

Fun fact: "/dev/nul" (with only one L) would have worked, even if there is no directory with that name.

That's been a feature since DOS 2.0, there was even an undocumented option AVAILDEV to make the prefix mandatory, instead of having device names present everywhere. But it broke the common trick used to detect if a directory exists ("if exist c:\some\path\nul").