AshamedCaptain
This is just the part how they deal with forward ABI problems, and is exactly the same that Be was doing too, as I mentioned in an above comment: private impl pointers and "preemptive" empty virtual functions (Be calls it "stuffing", OS X calls it "padding").
There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.
I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
While they claim "accuracy" as one of the goals for 86Box, I believe accuracy is overrated in PC emus (you don't really need that much accuracy due to the variety of PC clones, and emus are not that accurate anyway). For me the biggest point for using 86Box over other PC emulators/virtualizers is the large selection of virtual hardware available to emulate, not performance.
It's ridiculous also how you ban an IP then 1 second later another one picks up from where the first one left on.
You realize you're asking for a list of instructions that are not used by codegen but exist in the ISA? Because it is practically infinite.
Even a plain old "in" in x86 may go from clobbering only the target registers to clobbering memory to clobbering about _every_ register (e.g. under vmware). And there's a million like these on any architecture.
Short of generically saying all clobber everything, I really don't know how can you build a table here.
And you are forgetting that the problem does not only extend to the compiler here, but to whoever is writing the assembly, because you may be using some register that may or may not be clobbered on depending on which instruction operand size was used by the previous one!
> So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point
Some inline assembly syntax (e.g. Watcom) does support return an int64 as 2 registers. Are you understanding this as me asking to change the instruction to return the value in one register or something? What I'm saying is that it supports mapping its 64 bit native type (which is either two registers or always in memory, I don't care) to an inline assembly snippet that uses/returns an int64 value in two registers.
This is just an example of the reason inline assembly syntax grows unwieldly, and there are more! Just about any 'letter' of gcc's extended ASM is another one. You seem to be trying to implement something like intrinsics here, with a very limited view of what people use inline assembly for, and that's fine, but it simply falls short, and that is why you have a hard time explaining the decisions behind inline asm syntax.
How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask.
Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access.
I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID.
Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk.
And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.
No, you have tables _of the instructions that the compiler codegen may use_. You have no tables of what someone may use inside inline assembly, because for most architectures it may not even be possible to build such tables in the first place!. That's a reason why usually you rely on the users specifying the side effects manually for these cases.
> Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about.
You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers? Am I missing something here?
Even rdtsc is already returning a 64-bit into two registers (another x86 idiosyncrasy I suppose), rather than "two separate return values", something the examples kind of gloss over.
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
There are things that the "open source movement" dreams about, and one just has to search around... E.g. like codecs, Qualcomm's aptX lossless, adaptative, and other more recent variations.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
In GAS you can skip the width suffix from the mnemonic, and in most Intel assemblers you can skip the memory type operators like byte. They happily guess it from the operands. The problem is that on x86 (but also other ISAs, even if to a lower extent) the different operand sizes have a lot of side effects, which is why everyone just makes the operand size explicit, up to the point that apparently the author/LLM believes that it is mandatory to specify them.
This kind of defeats the headline of the article...
Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks. This is why everyone's inline assembly syntax looks like that, because they want to cover the weird cases (gcc's one is almost like an history book). You're normally using inline assembly for when you have some ridiculous corner case, if not, then what you ought to use is more akin to intrinsics...
Also it forgets Watcom C, which does have a complete but messy syntax for inline assembly (which combines nicely with its ability to specify really weird calling conventions).
It's not clear who it is protecting against, it does not seem to be effective at protecting against anything at all, it is actively annoying to the user, and has no way to disable. Perfect example of the usual "security theater" feature.
No such limits for LLMs where losing all your files is about par for the course for everyone who uses them regularly.
Porting Linux drivers to anywhere is generally hard. It either makes your kernel very Linux-like (and lots of manpower to translate the abstractions), or forces you to put Linux on it. There are bazillions of projects to put recent Intel drivers on 9x and none suceeded, for example.
Plus my recent observation that for Haiku it was easier to port the out-of-tree nvidia driver and fork Mesa, than it was to port the Linux amdgpu one.