LAHF and SAHF are an interesting rabbit hole themselves.
If you ever dug into x86 assembler programming... at first they make no sense at all. They only save/restore a tiny part of the available flag registers. The mnemonics themselves make little sense - load/store are not really used in any other base x86 mnemonics (unlike e.g. 6502 mnemonics, which use LD?/ST? instead of MOV like x86).
It only clicked when I read an Intel document about porting assembler code from the 8080 to the 8086.
LAHF/SAHF are basically convenience instructions to make porting easier. Many 8080 instructions did not alter the flags, unlike their 8086 counterparts. Substituting an `INX` instruction with `LAHF; INC; SAHF` made it possible to mechanically translate assembler source code.
And yeah, 8080 mnemonics had LDA and STA like the 6502...
dig manages to dig out ips for heise.de and tagesschau.de but not spiegel.de amazon.de and google.de However, dig @8.8.8.8 has still amazon.de cached, unlike 1.1.1.1 so perhaps Google to the rescue?
[Edit] After playing around with it, google seems to have at least some pages cached. After setting dns to 8.8.8.8 amazon.de and spiegel.de work again, my blog does not.
There is absolutely no need for this to exist in physical form. It is perfectly alright to run this on a simulation in Logisim Optimize as long as you desire and then once that is done, implementing it in physical form is just a matter of assembling it, which mostly can be done by many print pcb and solder on demand services.
TBH I still don't really get how it's different from MIPS. As far as I can tell... Loongson seems to be really just MIPS, while LoongArch is MIPS with some extra instructions.
Wait, this is a modern-ish ISA with a software-managed TLB, I didn’t realize that! The manual seems a bit unhappy about that part though:
> In the current version of this architecture specification, TLB refill and consistent maintenance between TLB and page tables are still [sic] all led by software.
At some point there were LCD monitors that had very noticeable to me chequerboard pattern - like with analogue TV, only half of the screen got lit up/refreshed, but with an alternating pattern rather than scan lines.
After asking the owner of said screen how he could stand that... "stand what?"
It’s not necessarily picky - it’s sometimes about physically different perception.
When DLP projectors first came out, I couldn’t watch them. I would see colors breaking in fast motion scenes and whenever I would move my head even slightly (and … we all move our head slightly often when watching a movie).
When I told other people, some of them nodded in understanding, but the vast majority thought I was making things up - for them, it was a rock solid picture.
One of my friends replied: “I can see about 300hz. Not all the time - only when I have secadic movements; but that means many fluorescents, DLPs and other light sources drive me crazy. I guess you’re also a member of crazy club”
Some people can hear 26khz. Some people can see DLPs. Some people can see the alternating pattern….
I had a (regrettable) 19" 4x3 ViewSonic display that made that problem obvious -- way back in 2008 or so.
My homework at that time revealed a couple of things:
1. Liquid crystals are individually driven by AC waveforms, not DC as one might assume. This is the nature of the beast. The frequency at which the signal alternates is not necessarily very high. Thus, sometimes, this alternating nature is visible.
2. Some displays use dithering. A given display might support just -- say -- 6 bits per subpixel. To get the full 8 or 10 or whatever number of bits that are expected as a final output, the in-between steps are approximated by switching between two values -- sometimes (again) at a fairly low frequency that is visible.
...
But anyway, that ViewSonic monitor: Most people thought it looked fine, but it drove me nuts.
You'd better be, we have certain expectations from you now /s
But more seriously... I don't think that Linux has ever been booted on a non-monolithic CPU (I wanted to say 'discrete cpu' first, but there's some PDP-11s with 4 chip CPUs)
one could argue that 4004 is it. It does not really do memory ops at all. all decoding for memory ops happens inside the memory chips. but yeah - not non-monolithic enough
I'm by no means an expert, but I've recently implemented a small BLE based IoT device, and had a look at the security/privacy of a medical BLE device.
Some points:
* there's a real lack of quality, up-to-date documentation. I would have thought that at least on Linux you'd find some documentation, but most of it seems to be "RTFS".
* BLE is in general very unfamiliar to most developers. There's no client and server, there's central and peripheral. GATT profiles are a mix between TCP connections and binary REST-ish interface.
* Encryption/authentication is possible, but depending on the manufacturer's API/quality of documentation it's not really apparent a. how to select a secure connection method b. how to even check if and which authentication/encryption was chosen
* Coming from the previous point, many BLE devices have the same generic GATT profiles, sometimes with the same sample data. This looks like a lot of BLE devices just copy&pasted sample code from the manufacturer and added the minimal changes "to make it work"
* It's probably really easy to do passive/active fingerprinting to find out the manufacturer and/or chip version used in a device. Default services, ordering of advertising options etc
* Many BLE devices are not conformant. Uninitialised name fields with garbage in them ("Device Name: WHOOP\020��=u5״\023n"), manufacturers using random identifiers that clearly don't belong to them
* when doing passive BLE sniffing: the biggest obstacle isn't getting data. It's how to filter it. One of the most useful filters of the nRF Connect app for android is to filter out all advertisement packages for apple and ms devices, to cut down the overwhelming amount of such devices
If you ever dug into x86 assembler programming... at first they make no sense at all. They only save/restore a tiny part of the available flag registers. The mnemonics themselves make little sense - load/store are not really used in any other base x86 mnemonics (unlike e.g. 6502 mnemonics, which use LD?/ST? instead of MOV like x86).
It only clicked when I read an Intel document about porting assembler code from the 8080 to the 8086.
LAHF/SAHF are basically convenience instructions to make porting easier. Many 8080 instructions did not alter the flags, unlike their 8086 counterparts. Substituting an `INX` instruction with `LAHF; INC; SAHF` made it possible to mechanically translate assembler source code.
And yeah, 8080 mnemonics had LDA and STA like the 6502...