The non-obvious bit is why there isn't an even faster and shorter "mov <register>,0" instructions - the processors started short-circuiting xor <register>,<register> much later.
While xor eax, eax only uses 2 bytes. Since there are only 8 registers, meaning they can be encoded with 3 bits, you can pack two values into the <Registers> field (ModR/M).
Making mov eax, 0 only take two bytes would require significant changes of the ISA to allow immediate values in the ModR/M byte (or similar) but there would be little benefit since zeroing can already be done in 2 bytes and I doubt that other cases are even close to frequent enough for this to be any significant benefit overall. An actual improvement would be if there was a dedicated 1 Byte set-rax-to-0 instruction, but obviously that comes at a tradeoff where we have to encode another operation differently (probably with more bytes) again (and you can't zero anything else with it).
Some other architectures like PDP-11 and 680x0 had a dedicated "clear register" instruction.
It could have been added to x86, even as a group of single-byte opcodes with the register encoded in three bits (as with PUSH, POP, and INC/DEC outside of long mode). But the XOR idiom was already established on the 8080 by that point.
A number of the RISC processors have a special zero register, giving you a "mov reg, zero" instruction.
Of course many of the RISC processors also have fixed length instructions, with small literal values being encoded as part of the instruction, so "mov reg, #0" and "mov reg, zero" would both be same length.
Right, like a “set reg to zero” instruction. One byte. Just encodes the operation and the reg to zero. I’m surprised we didn’t have it on those old processors. Maybe the thinking was that it was already there: xor reg,reg.
One byte instructions, with 8 registers as in the 8086, waste 8 opcodes which is 3% of the total. There are just five: "INC reg", "DEC reg", "PUSH reg", "POP reg", "XCHG AX, reg" (which is 7 wasted opcodes instead of 8, because "XCHG AX, AX" doubles as NOP).
One-byte INC/DEC was dropped with x86-64, and PUSH/POP are almost obsolete in APX due to its addition of PUSH2/POP2, leaving only the least useful of the five in the most recent incantation of the instruction set.
There are only 256 1-byte opcodes or prefixes available, if you take 8 of these to zero registers, they won't be available for other instruction, and unless you consider zeroing to be so important that they really need their 1-byte opcodes, it is redundant since you can use the 2-byte "xor reg,reg" instead, hence the "waste'.
In addition, you would need 16 opcodes, not 8, if you also wanted to cover 8 bit registers (AH/AL,...).
Special shout-out to the undocumented SALC instruction, which puts the carry flag into AL. If you know that the carry will be 0, it is a nice sizecoding trick to zero AL in 1 byte.
They occupy 8 of the possible 256 byte values. Together, those five cases used about 15% of the space.
Though I was forgetting one important case: MOV r,imm also used one-byte opcodes with the register index embedded. And it came in byte and word variants, so it used a further 16 opcodes bytes for a total of 56 one byte opcodes with register encoding.
Gotcha, thanks for clarifying. I was reacting to the word “waste” I guess. Surely, as you say, it consumes that opcode encoding space. Whether that’s a waste or not depends on a lot of other things, I suppose. I wasn’t necessarily thinking x86-specific in my original comment. But yea, if you try to zero every possible register and half-word register you would definitely consume lots of encoding space.
Traditionally in x86, only the first byte is the opcode used to select the instruction, and any further bytes contain only operands. Thus, since there exist 256 possible values for the initial byte, there are at most 256 possible opcodes to represent different instructions.
So if you add a 1-byte instruction for each register to zero its value, that consumes 8 of the possible 256 opcodes, since there are 8 registers. Traditional x86 did have several groups of 1-byte instructions for common operations, but most of them were later replaced with multibyte encodings to free up space for other instructions.
special mov 0 instruction times 8 registers. The opcode space, especially 1 byte opcode space, is precious so encoding redundant operations is wasteful.
Instruction slots are extremely valuable in 8-bit instruction sets. The Z80 has some free slots left in the ED-prefixed instruction subset, but being prefix-instructions means they could at best run at half speed of one-byte instructions (8 vs 4 clock cycles).
Yes it does, unlike before, a shits-and-giggles attacker could change all the tags in an aisle into "you're gay" without showing anything on surveillance cameras.
He wouldn't gain anything but the store would lose.
But actually: It's not that broad. It's still mostly one at a time, ish. Changing a lot of them would stand out if anyone were paying attention.
Although it could certainly be broadened...but an IR emitter that's skookum enough to reliably hit all of the shelf tags in an aisle at once would probably show up as an intensely-bright purple floodlight on the cameras. That would stand out quite a lot. :)
Well it does need to read individual tag barcodes, so it is indeed one at a time, still you could make an automated camera+beam device, hide at chest level, walk through an aisle as if looking for something, then pick up something in the end of the aisle and go to checkout.
I don't think anyone is paying attention anywhere near enough to pick that up. Additionally, one could read some barcodes and make quite cheap battery-powered narrow beam emitters to be placed in store aimed at particular tags that would only power up once a day at a random time.
If the lulz are the point, then: Just build hide the thing in the floor-cleaning robot. Include a decent camera (they're very cheap) to catch the barcodes.
If the comms last long enough as the machine passes by to program some tags every night, then some tags get programmed every night. Nobody will pay attention to the robot's new purple floodlight in the cameras.
How is that achievable? PIs can legally do it. Random people can keep tabs on you and exchange gossip. It's the sudden scale and low cost that doesn't sit well with freedom to not be tracked in public 24/7 we took for granted.
The core ill is aggregated data, because that's what allows the mass in surveillance, data mining, etc.
The collection actions are almost immaterial. Without persistence they must be re-performed for each request, which naturally provides a throughput bottleneck and makes "for everyone" untenable.
If we agree the aggregated data at rest is the problem, then addressing it would look like this:
1. Classify all data holders at scale into a regulated group
2. Apply initial regulations
- To respond to queries for copies of personal data held
- To update data or be liable in court for failing to do so
- To validate counterparties apply basic security due diligence before transferring data (or the transferer also faces liability)
- To maintain a *full* chain of custody of data (from originator through every intermediate party to holder) so that leaks / misuse can be traced
- To file yearly update on the types, amount of data, and counterparties it was transferred to with the federal government that are made public
The initial impediment to regulatory action is Google, Meta, Equifax, etc. saying "This problem is too complex and you don't understand it."
It's not. But the first step is classifying and documenting the problem.
The only way is through - everybody should get into the practice of stalking and gossiping about each other in a Molochian environment, where the people who do not do so suffer from the losing side of an information asymmetry.
Expect AI, especially post-Mythos, to just enable this at even further scale. Consumer grade wireless networking gear as a whole is a very wide attack surface and is basically never updated.
It is not realistic to say that no person is allowed to keep track of another person; watch where they go, when, with who, etc.
It should not be acceptable for a company to gather information on "everyone"; where they have been going, when, with who, how often, etc. And it should not be acceptable for them to sell that information (to government agencies OR private citizens).
It's a matter of scale.
- Making the first one illegal/impossible would be difficult/costly; and not doing so has a limited impact (to society, not to the single person affected).
- Making the second one illegal is much easier, and it's much easier to shut down a large company doing it than it is 1,000 individual stalkers. The impact of making it illegal is much wider and better for society as a whole.
We don't want anyone being stalked. But in a cost/benefit analysis, we can do something about one of them but not the other.
If PIs can "legally" do it then it sounds like there is a law which allows them to do it. That law can be revoked (unless the power comes from Constitution which would make it effectively impossible to revoke).
Note that PIs are effectively illegal under GDPR by default. They would generally need to provide Article 13 notice, i.e. you would become aware of them unless they were just asking around without actually following you. Member states can make them legal though (via Article 23) and likely in many cases they have done so.
In the US, PI licensing is only about PIing for hire. The actual act of going through public records, following cars and whatnot do not require a license, you can spy on anyone without a license as long as you don't get paid for it.
EU is more complicated, but Article 14.5.b allows withholding notice if it would impair/defeat the purpose of processing. The PI must however apply "safeguards", whatever it could mean.
Article 14(5)(b) does, but that only applies for Article 14 notice (personal data not directly obtained from data subject). Article 13 (personal data obtained directly from data subject) does not have such exception in GDPR itself.
This becomes extremely relevant when you read it in the light of the C-422/24 decision. In that personal data collected via body worn cameras was determined to be "directly obtained". Paragraph 41 from the judgement:
> If it were accepted that Article 14 of the GDPR applies where personal data are collected by means of a body camera, the data subject would not receive any information at the time of collection, even though he or she is the source of those data, which would allow the controller not to provide information to that data subject immediately. Therefore, such an interpretation would carry the risk of the collection of personal data escaping the knowledge of the data subject and giving rise to hidden surveillance practices. Such a consequence would be incompatible with the objective, referred to in the preceding paragraph, of ensuring a high level of protection of the fundamental rights and freedoms of natural persons.
Given this it's very unlikely that PI observing (especially if they record) could be considered to be Article 14 instead of Article 13 type of collection as it's exactly "hidden surveillance practice" that the Court warned about.
Member states do have a right to restrict the Article 13 disclosure obligations via Article 23 restriction, but that requires specific law in the member state & the law itself must fulfill the obligations that Article 23 requires. Article 23(2) essentially forbids leaving everything up to the controller.
And as far as PI in the US goes, actions between stalking and PI "for self" tend to be so similar that I wouldn't necessarily recommend anyone to try it.
reply