Darek Mihocka

It's amazing how far we've come in raw computing resources available on a desktop in 40 years. Check the 2018 video of an Atari 8-bit emulator which can run 182 apps simultaneously (no idea what CPU is powering the box): http://www.emulators.com/xformer.htm#XFORMER10

Mainly what I want to do is use ARM64 and abandon Intel, so I don't look at options like that. It's pretty clear that the x86 ISA has retarded the state of the art in computing for the past couple decades. The byzantine encodings make it mathematically impossible to write an optimal compiler for today's x86 instruction set. http://www.emulators.com/docs/nx05_vx64.htm http://www.emulators.com/docs/nx06_rmw.htm Of course, compiler writers still chase after greater performance, which leads to optimizations of questionable value (and demonstrable harm). http://blog.regehr.org/archives/1307 Throw away all that cruft, use a clean instruction set, and compilers can go back to being small and fast, easily generating output that is also small and fast.

> I get that serious emulators invest effort in making dispatch fast, and that a naive for/switch loop is not the fastest way to dispatch instructions If you're the kind of masochist that enjoys optimizing dispatch loops (hi, you're not alone), check this out: http://www.emulators.com/docs/nx25_nostradamus.htm One of the best resources out there for this sort of stuff.

Great article but I was really put off by this bit, which aside from being very condescending, simply isn't true and reveals a lack of appreciation for the innovation that I would have thought someone posting about target triples and compilers would have appreciated: > Why the Windows people invented a whole other ABI instead of making things clean and simple like Apple did with Rosetta on ARM MacBooks? I have no idea, but http://www.emulators.com/docs/abc_arm64ec_explained.htm contains various excuses, none of which I am impressed by. My read is that their compiler org was just worse at life than Apple’s, which is not surprising, since Apple does compilers better than anyone else in the business. I was already familiar with ARM64EC from reading about its development from Microsoft over the past years but had not come across the emulators.com link before - it's a stupendous (long) read and well worth the time if you are interested in lower-level shenanigans. The truth is that Microsoft's ARM64EC solution is a hundred times more brilliant and a thousand times better for backwards (and forwards) compatibility than Rosetta on macOS, which gave the user a far inferior experience than native code, executed (sometimes far) slower, prevented interop between legacy and modern code, left app devs having to do a full port to move to use newer tech (or even just have a UI that matched the rest of the system), and was always intended as a merely transitional bit of tech to last the…

People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed, other factors like enhanced hardware flag conversion support and function call optimizations play a significant role too: http://www.emulators.com/docs/abc_exit_xta.htm

Take look at the Nostradamus Distributor: http://www.emulators.com/docs/nx25_nostradamus.htm

2 things. 1. Excel now-a-days is mostly just an electron app. That's what the office 365 conversion was effectively. 2. MS has supported ARM platforms for quite some time now. [1] [1] https://www.windowscentral.com/office-windows-11-arm-starts-rolling-ou… [2] http://www.emulators.com/docs/abc_arm64ec_explained.htm

I found the http://www.emulators.com/docs/abc_arm64ec_explained.htm article extremely helpful at understanding what the ABI is doing, you might like it too.

I think it's also a chicken and egg problem. How many people have Windows ARM laptops, and how much incentive / how easy is it for developers to make their apps ARM-native? There was some talk earlier about the Windows equivalent to 'fat-binaries', the new ABI and executable format. http://www.emulators.com/docs/abc_arm64ec_explained.htm https://news.ycombinator.com/item?id=39806746

Yes, saving and restoring flags is very expensive. I thought about talking about that in the article but figured that was too much of a detour. Darek Mihocka wrote a really interesting article about how to optimize flag calculations in an x86 emulator: http://emulators.com/docs/nx11_flags.htm Although looking at your username I suspect you may have read this one before...

For a micro, see iAPX 432. It was considered over-complicated for its time but if CHERI catches on, perhaps far ahead of its time. Also interesting to me was the idea in Darek Mihocka's blog NO EXECUTE! about using emulation to implement advanced processor features rather than forcing everything through a one size fits all hardware policy. Of course emulation will always have a performance hit, but the concept is interesting. http://emulators.com/nx_toc.htm

It's an interesting take, and I agree with the issue being the x86 difficulties. There was a link today about "how many registers an x86 processor has" and it really reminded me of how many issues and legacy the processors have to deal with I think the solution would be to move the x86 cruft to an SW emulation layer, and focus on base performance. Something like this (though I'm skeptical of taking things like rings and memory protection out of hw http://www.emulators.com/docs/nx03_10fixes.htm ) Your latest Intel chip boots like an 8086 from the 70s and it has to do several steps before it goes to protected mode. It has to deal with x87, MMX, SSE, SSE2, AVX etc (ARM has NEON and that's it.). Every register has several ways of being accessed: AH/AL, AX, EAX, RAX. Wanna access a partial part of a register on ARM? AND/Shift.

Sure this is neat stuff, but I don't think any of it is novel. Bochs is a good source for some bytecode vm performance wizardry [1], even if the bytecode in question is the x86 ISA. Regardless, kudos to the authors and nice to see a fast wasm interpreter done well. 1: http://www.emulators.com/docs/nx25_nostradamus.htm

There are some interesting articles here: http://emulators.com/nx_toc.htm, where Darek Mihocka advocates a similar approach; however pushing for emulation rather than JIT.

Darek Mihocka has a nice writeup on inner interpreter efficiency on modern-ish architectures: http://www.emulators.com/docs/nx25_nostradamus.htm [edit: get his name right. you'd think i'd know it, since he rubs my nose into some bugs I wrote 30+ years ago every time we meet. hi, darek! :-)]

http://www.emulators.com/docs/LazyOverflowDetect_Final.pdf This paper seems to imply that that high level languages can't access the carry bit, yet C#'s checked mechanism uses it. I've been using -ftrapv with gcc for a long time, from here: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options. From the code you posted, and the assembly[1] emitted in the pdf above I can't see the optimiser taking advantage of the carry bit. No mention of CF, OF: [1] lea ebx, DWORD PTR [edi+eax] cmp ebx, edi jae SHORT $LN4@unsigned_c cmp ebx, eax jae SHORT $LN4@unsigned_c mov ecx, 1 jmp SHORT $LN5@unsigned_c xor ecx, ecx The gcc flag ftapv only works for signed integers, not clear what the carry bit behaviour is for unsigned integers.

The situation with x86 specifically is a little weirder than that: http://www.emulators.com/docs/nx06_rmw.htm . It's a bit of a long read, but the summary is that on some x86s, single-instruction adds to memory are faster, and on others, load/increment/store in three instructions is faster. Compiler optimization be a harsh mistress.

Hey here's a good article from a old friend of mine about one somewhat tricky part which is the ALU / arithmetic flags (which he gets to after rambling a bit about various x86 simulation techniques) http://www.emulators.com/docs/nx11_flags.htm

And here is more from Darek Mihocka: http://www.emulators.com/docs/nx25_nostradamus.htm

The content of the website is beyond awesome. http://www.emulators.com/docs/nx33_qemu_0125.htm first caugth my eye. then http://www.emulators.com/docs/nx30_bochs245.htm

I found this interesting near the end: http://emulators.com/docs/nx13_olpc.htm. The author wonders about A New Era For Personal Computing? I think three years later, a lot of us are starting to see through to the other side. Funny that he mentioned the Newton, too.

For the longest time, I swore by computed goto as well. But it has its share of problems; it's not very portable; it forces the code into a rigid, non-extendable format; and it's not as efficient as commonly assumed. I'm far from the first person to notice [0], so don't bother shooting the messenger. My latest project [1] simply calls into a struct via a function pointer for each instruction. With a twist. Since it returns the pointer to the next operation and uses longjmp to stop the program, which means I can get away without lookups and without a loop condition. And as an added bonus the code is much nicer to deal with and more extendable, since the set of operations isn't hardcoded any more. Comparing language performance is tricky business, but it mostly runs faster than Python3 from my tests so far. My point is that computed goto is not the end of the story. I'll just add that there are many different ways to write a VM; the one posted here is very low level, the one linked below reasonably high level. Using physical CPUs as inspiration is all good, but there's nothing gained from pretending in itself unless you're compiling to native code at some point. [0] http://www.emulators.com/docs/nx25_nostradamus.htm [1] https://gitlab.com/sifoo/snigl