You would have to give the compiler some help to allow it to auto-vectorize this. Warning, untested: https://godbolt.org/z/b358bMWzG. This unrolls the loop by 16 times. The trick is using `&` instead of `and` so that there's no short-circuiting. All 16 elements are read on each iteration of the loop. This gives the compiler the freedom to replace these reads with a single 16 byte load.
> compilers will never auto-vectorize loops with an early loop break afaik.
I'm not clear on why there is `ip++` in the RECORD_INST handler. We've already moved to the next instruction by running `ip++` at the end of the handler in the normal dispatch table. In the RECORD_INST handler we do the work to record the instruction but don't do the actual work of that instruction. We can't, because we only have the one handler that has to work for all instructions. Shouldn't we jump to DISPATCHER_TABLE_NORMAL without incrementing ip again?
If they had extra pins that they had no use for, I'm sure this would have seemed like a very easy and cheap addition. You take 4 unused pins and add 4 pulldown resistors. Then when you go to draw the background, instead of using index 0, you take the value for the index from those pins.
Maybe they planned to use this in arcade hardware, where you'd have a bigger budget than a home console and could afford two PPUs. Then you'd get more colors, and you could scroll the background layer independently from the foreground layer. I believe they later added support for independent layers on the SNES hardware so this type of thing was probably already in demand from game designers.
The one that immediately springs to mind is C#. Of all the mainstream languages it is probably the one most similar to Java. It can be compiled into platform-independent bytecode (like Java) or into native code using Native AOT. Relevant to the subject of this article, it has had support for structs (user-defined value types) since C# 1.0 in 2002.
I'm a bit confused about the colors used in the CPU graphs. In the first graphs it looks like green means that the application is running and red means that the GC is running. But once we get to Figure 4 then red means the GC is running (on the GC threads) or nothing is running (on the Main thread)? If red always means that GC work is being done on that thread then this is inconsistent with the text that says "By distributing reclamation work across both cores..." since we would have three threads running at once. Once you move to the concurrent GC figures you definitely have three things running at once. Unless you're assuming SMT with each core running two threads?
That would probably be difficult at optical wavelengths. At radio wavelengths you might have a better shot, but we can build radio interferometric telescopes on Earth and since the atmosphere is relatively transparent at radio frequencies, you probably aren't going to get any advantage by trying to build one in Earth orbit.
It depends on what you want. If you want to install an old copy of Visual Studio from 20 years ago then you should be able to write a program and compile it and have that work on XP. But that comes with limitations. You're not going to be able to use even C++11 and will be stuck with C++03, or maybe even C++98. If that's acceptable to you then it can work. But if you want to compile something that somebody else wrote or want to use some library that somebody else wrote, it probably won't work in that environment.
Or you could install and old copy of Cygwin or MinGW.
Do you want to run a modern Visual Studio and target XP? Maybe you can make that work if you install an old platform SDK and set WINVER and _WIN32_VERSION and work around all the warnings and compatibility problems that you'll run into. It is fighting an uphill battle and it will continue to get worse with each new version of VS that you want use.
For rust there is Rust9x https://seri.tools/blog/announcing-rust9x/. But I think this is the effort of handful of people. It is behind the upstream rust and it could go away at any time. If you want to write a toy program in Rust then it is fine, but if you want something that's going to be supported long-term you're rolling the dice.
Python 3.4.4 is the last version of Python that will run on Windows XP. That's 10 years old and many things on PyPI now require newer versions of Python so you'd be stuck with old, unsupported versions of those modules, possibly containing security issues.
I feel like it is unfair to blame the compiler when you've explicitly asked for `/O1`. If you change this to `/O2` or `/Ox` then MSVC will optimize this into a constant 5, proving that it does "know" that strlen will return 5 in this case.
If you want to tell the compiler not to worry about the possible buffer overrun then you can try `int foo(char const s[static 4])`. Or use `&` instead of `&&` to ensure that there is no short-circuiting, e.g. `if ((s[0] == 'h') & (s[1] == 'e') & (s[2] == 'l') & (s[3] == 'l'))` Either way, this then compiles down to a single 32-bit comparison.
Interestingly, it is comparing against a different 32-bit value than `bar` does. I think this is because you accidentally got the order backwards in `bar`.
The code in `bar` is probably not a good idea on targets that don't like unaligned loads.
I also used mingw and yet I arrived at different results. Maybe it was a different version, or a different distro of MinGW, or a 32-bit vs. 64-bit issue, or I'm linking against a different CRT. Without details from OP, we can't really tell.
I tried to reproduce this binary to see what the 278 KB was being taken up by. The first obstacle that I ran into was that the build.bat file doesn't work if you have git configured to use core.autocrlf=false. Changing that to core.autocrlf=true and recloning was sufficient to get me building.
I'm using x86_64-15.1.0-release-win32-seh-msvcrt-rt_v12-rev0.7z from https://github.com/niXman/mingw-builds-binaries/releases/tag... as the toolchain. This produces a 102 KB .exe file. Right off the bat we are doing much better than the claimed 278 KB. Maybe the author is using a different toolchain or different settings? Exact steps to reproduce would be welcome.
We can improve this by passing some switches to GCC.
It seems like it should be possible to factor out most of the iterator boilerplate into a helper class. Then each place where you want to iterate you can construct an instance of that helper class and supply a lambda that specifies how to descend into children. If you're doing the same iteration in several places then you can use a named function instead of a lambda, which means less typing for each `for` loop. Here's a rough sketch: https://godbolt.org/z/x94WY77rv
> compilers will never auto-vectorize loops with an early loop break afaik.
I think this is changing. https://godbolt.org/z/ea1E7dx9v. GCC 14 won't try to vectorize this because of the break statement. But GCC 15 does vectorize it. This got a callout in the "General Improvements" section of the release notes: https://gcc.gnu.org/gcc-15/changes.html
I don't think there's any equivalent in clang/LLVM.