> I have explained in another comment that the only CPUs where XOR can be faster than subtraction are the so-called superpipelined CPUs. Superpipelined CPUs have been made only after 1990 and there were very few such CPUs.
(And I'm choosing 386 to avoid it being "a superpipelined CPU".)
> Or you do not consider MUL/DIV "arithmetic", or something.
Multiplier and divider are usually not considered part of the ALU, yes. Not uncommon for those to be shared between execution threads while there's an ALU for each.
386 is a microprogrammed CPU where a multiplication is dome by a long sequence of microinstructions, including a loop that is executed a variable number of times, hence its long and variable execution time.
A register-register operation required 2 microinstructions, presumably for an ALU operation and for writing back into the register file.
Unlike the later 80486 which had execution pipelines that allowed consecutive ALU operations to be executed back-to-back, so the throughput was 1 ALU operation per clock cycle, in 80386 there was only some pipelining of the overall instruction execution, i.e. instruction fetching and decoding was overlapped with microinstruction execution, but there was no pipelining at a lower level, so it was not possible to execute ALU operations back to back. The fastest instructions required 2 clock cycles and most instructions required more clock cycles.
In 80386, the ALU itself required the same 1 clock cycle for executing either XOR or SUB, but in order to complete 1 instruction the minimum time was 2 clock cycles.
Moreover, this time of 2 clock cycles was optimistic, it assumed that the processor had succeeded to fetch and decode the instruction before the previous instruction was completed. This was not always true, so a XOR or a SUB could randomly require more than 2 clock cycles, when it needed to finish instruction decoding or fetching before doing the ALU operation.
In very old or very cheap processors there are no dedicated multipliers and dividers, so a multiplication or division is done by a sequence of ALU operations. In any high performance processor, multiplications are done by dedicated multipliers and there are also dedicated division/square root devices with their own sequencers. The dividers may share some circuits with the multipliers, or not. When the dividers share some circuits with the multipliers, divisions and multiplications cannot be done concurrently.
In many CPUs, the dedicated multipliers may share some surrounding circuits with an ALU, i.e. they may be connected to the same buses and they may be fed by the same scheduler port, so while a multiplication is executed the associated ALU cannot be used. Nevertheless the core multiplier and ALU remain distinct, because a multiplier and an ALU have very distinct structures. An ALU is built around an adder by adding a lot of control gates that allow the execution of related arithmetic operations, e.g. subtraction/comparison/increment/decrement and of bitwise operations. In cheaper CPUs the ALU can also do shifts and rotations, while in more performant CPUs there may be a dedicated shifter separated from the ALU.
The term ALU can be used with 2 different senses. The strict sense is that an ALU is a digital adder augmented with control gates that allow the selection of any operation from a small set, typically of 8 or 16 or 32 operations, which are simple arithmetic or bitwise operations. Before the monolithic processors, computers were made using separate ALU circuits, like TI SN74181+SN74182 or circuits combining an ALU with registers, e.g. AMD 2901/2903.
In the wide sense, ALU may be used to designate an execution unit of a processor, which may include many subunits, which may be ALUs in the strict sense, shifters, multipliers, dividers, shufflers etc.
An ALU in the strict sense is the minimal kind of execution unit required by a processor. The modern high-performance processors have much more complex execution units.
Most of mul/div was implemented in hardware since the 80186 (and the more or less compatible NEC V30 too). The microcode only loaded the operands into internal ALU registers, and did some final adjustment at the end. But it was still done as a sequence of single bit shifts with add/sub, taking one clock cycle per bit.
I mean, make sense, of course. How else could they possibly know what users want? Run a bug tracker? Use their own software? Have more than one 9 of uptime? /s
Corporations can and will do every scummy thing permitted to them by law, so here we are. Until the US grows a backbone on issues of privacy, we shouldn't be surprised, I suppose. But the US won't be growing such a backbone anytime in the near future.
> if you're going to "rewrite" something with AI, proofread it, especially technical documentation.
The entire idea of AI, AFAICT, is to avoid the work that is necessary to understand the thing, which would then permit you to proofread (for technical accuracy, not just grammatical well-formed-ness), let alone write it in the first place.
> How many hours were burned (and money) over some AI generated goof?
But you see, the person whose hours were burned was the parent, here, not the person using the AI. The person feeling the pain is not the person who needs to learn the lesson.
(Why you'd take the parent's docs and just run them through a slop-shredder is another question, but I can see the reasons along the lines of "sprucing them up" or "enriching them", etc.)
* It's an ad / undisclosed conflict of interest. (They appear to be a photo hosting site in competition with, e.g., Google Photos.)
* The TOS deigns itself to claim forced arb. over you.
(AFAICT, it's just running uploads through an AI? I don't think the actual Google product has these features, we've just asked an AI to hallucinate the biases of two people sitting under a tree, but now (this is according to the actual linked site) — they're probably lesbians.
I.e., it seems like the likely thing here is that the (undisclosed) prompt that generated this is from them, not from Google. Or, showing your work goes a long way towards building the trust that this isn't simple fear mongering, and while I think there's a good argument for being careful of what one uploads to a corporation on the Internet, "upload to this corporation instead" feels like a "fool me once…" type of solution.)
Yeah, wow, the comments weren't kidding. This'll probably be the best video I watch all month, at least, if not more. I would have said what she was trying to do was "impossible" (had I not seen the title and figured … well … she posted the video) and right about when I was thinking that she got me with:
> Hold on a second. That's a really bad excuse. And technology never got anywhere by saying I accept this and it is what it is.
You're presumably referencing Missouri v. Biden, to which the EFF did file an amicus[1]. In it, they note,
> Many platforms have potentially problematic “trusted flagger” programs in which certain
groups and individuals enjoy “some degree of priority in the processing of notices
> Of course, governmental participation in content moderation processes raises First Amendment issues not present with non-governmental inputs
With their overall opinion being something like "content moderation is normal, the government flagging content is also normal, and there are instances where the government's flagging of content moderation can be fine & not run afoul of 1A, but there are instances where it can, and we urge the court to think"
Note in this case, the platform was removing the content. The government was, in one respect, merely asking. (There were assertions that in other instances, such as public statements, the case was less so.) The court eventually ruled, and the ruling I saw from the 5th circuit seemed reasonable. (I think that was a preliminary injunction. AIUI, the case as a whole was never ruled on, because the Trump administration took over.)
Neither of those create a non-UTF-8 filename. (Both files are named "list0", which is valid UTF-8.) They have non-UTF-8 content, but that's not weird.
But it's not too hard to get a non-UTF-8 filename:
Both zsh & bash support that syntax.(You could also use process substitution with printf, but that's more steps than necessary. So, something closer to your example would be,
You can't put a \0 in the filename, as there's no way to pass that string in C.)reply