stsquad
|
4 months ago
|
on: Forth: The programming language that writes itself
In my first proper job as a software engineer I wrote a bunch of Forth for "fruit machines". I don't know what the US equivalent would be but they are low stakes gambling machines which are quite common in UK pubs. The core processor was a 6809 and Forth was chosen because the interpreter was super small and easy to implement. I really appreciated the quick interactive way you could update and tweak code as you tested it. I did get slightly weary of having to keep the state of the stack in your head as you DUP and SWAP stuff around but that was probably due to my inexperience and not decomposing things enough.
They continued to use Forth as the basis for their 68000 based video gaming machines although when it came to the hand classifier for video poker we ended up using C - mostly because we wanted to run a lot of simulations on one of these new fangled "Pentium" processors to make sure we got the prize distribution right to meet the target repayment rate of ~98%.
stsquad
|
6 months ago
|
on: KVM Forum 2025
stsquad
|
2 years ago
|
on: Could we stop Yellowstone from erupting with a geothermal power plant?
Isn't this basically the background to HZD: Frozen Wastes? A failing geoengineering project to keep Yellowstone stable.
stsquad
|
2 years ago
|
on: Mixtral of experts
I think they mean the assumed parameter size of GPT-4 is so large you couldn't run it on commodity hardware even if you could get hold of the model.
stsquad
|
3 years ago
|
on: QEMU 7.0
The plugins have access to the instruction stream to make architecture specific decisions. What I meant by architecture independent is that it doesn't involve per-guest annotations in the frontends to handle - any guest using the common translator loop (which is all of them now) can be instrumented by plugins.
However I absolutely agree its not currently as full featured as we would like. The next step when I get time is re-factoring the handling of register values in the core QEMU code so we can expose them to the plugins in a clean API.
stsquad
|
3 years ago
|
on: QEMU 7.0
The upstream now has TCG plugins (
https://qemu.readthedocs.io/en/latest/devel/tcg-plugins.html) which allow for a degree of instrumentation. The implementation is architecture agnostic and also tested within the code base. There are still features missing but it does provide a base for dynamic analysis of guest code.
stsquad
|
4 years ago
|
on: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak
The 64bit Aarch64 ISA has very little in common with the original ISA from '85.
stsquad
|
5 years ago
|
on: The Evolution of the QEMU Translator
AIUI that is mainly achieved by running the native library functions.Given how much time you spend in library functions I'm not surprised it has an edge over the full translation of the application.
stsquad
|
5 years ago
|
on: Huawei ExaGear: x86_64 apps on Arm 64-bit Linux systems
Since v4.0.0 (see
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a94b783952cc...). We are always up for improving the code generation quality but of course there is a trade off with JITs given we are not compilers. I suspect there are still big wins if we can come up with a reasonable solution for re-generating a hot-path of basic blocks with much better optimisation.
stsquad
|
5 years ago
|
on: Huawei ExaGear: x86_64 apps on Arm 64-bit Linux systems
We do use the host FPU for a subset of floating point operations now. However it only really works for clean 32/64 IEEE FP so anything that goes through the x87 still needs software emulation.
stsquad
|
6 years ago
|
on: Cross-ISA Machine Instrumentation Using Fast/Scalable Dynamic Binary Translation [pdf]
I should point out that the awesome part of this work is unlike a lot of academic exercises this was done in collaboration with the community. As a result much of the work is merged upstream and QEMU gets to benefit.
They continued to use Forth as the basis for their 68000 based video gaming machines although when it came to the hand classifier for video poker we ended up using C - mostly because we wanted to run a lot of simulations on one of these new fangled "Pentium" processors to make sure we got the prize distribution right to meet the target repayment rate of ~98%.