AshamedCaptain

So, exactly like what Mac OS X did with IO Kit. They managed for several decades...

Not at all. IO Kit was raw, pure C++, with all the ABI consequences you must deal with (including fragile base class). Just go to see any header of any exported IOKit class to see what I am talking about.

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.

I'll note that Mac OS X used a C++ ABI in the _kernel_....

And basically only used by those allergic to Samba's GPLv3.

Kind of proving why accuracy is not really that important for the PC world. Most era firmware would have tried to run on as much variety of machines possible.

Or a Rosetta-based emulator (like Parallels). But 86Box is going to be very bad there.

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.

That's Box86 [not a joke].

When actually it should be software companies that should be worried. If you believe like some guys do that you can just point an LLM to any piece of software in the world and ask it to patch it / replicate it / maintain it with zero copyright repercussions, what is the point of software companies again?

There have been shitloads of open source RADs. They do not generate much interest.

I once worked on a handheld garmin gps that used a 386 ... not sure if it ever became a product, though. It definitely had moving map... 1MB of it.

Right until you release it and a minor gets the NPC to talk about rape or something.

No and you missed the "freedom" part of the adage.

While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free. Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.

This is bad enough that I'm going to stop serving cgit. I've been doing cvsweb, then subversion, then cgit over my home server for many many years and for the first time ever this is annoying my own bw usage.

It's ridiculous also how you ban an IP then 1 second later another one picks up from where the first one left on.

> Name the architectures and the specific instructions; do not be hypothetical.

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 'mul' 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 unwieldy, 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.