psfAs for why I have been hacking on #DesmetC... look how well it fits on my #HP200LX! 300KB for a compiler is pretty sick (and will be even cooler if I can keep it near this small while supporting full C89); compile times are quite fast (for hello world, at least): overall it is a very pleasant tool to use on these small machines.
btw the #ELKS maintainer has also been hacking on #DesmetC and has his own fork (though still closely related to the main DOS repo) that is able to compile an increasingly large amount of stuff natively from within ELKS 
It's great seeing ongoing interest in on-target 8086 development, as opposed to just cross builds.
It's great seeing ongoing interest in on-target 8086 development, as opposed to just cross builds.
This was one of the more hair-raising changesets to prepare, but now unsigned long is available in my fork of #DesmetC and I've opened a pull request to the main project: https://github.com/the-grue/OpenDC/pull/12
We're up to 39,277 test cases now, which have been very handy in catching stupid bugs and bootstrapping-failures I introduced.
Since I started work on the project,
- The compiler front-end has grown from 54784 to 57856 bytes.
- The compiler back-end has grown from 51712 to 52736 bytes.
- The C library has grown from 56365 to 57027 bytes.
Adding 2 data types in 4758 bytes isn't bad, I think? #retrocomputing
It appears I've managed to get #DesmetC to support the 32-bit unsigned long type, as well as the U and LU suffixes on integer constants.
This changeset introduces a potential bootstrapping problem, because the brand-new unsigned long type is used in the same changeset that introduces it. I've got working binaries so it doesn't matter, but I probably should split this into two commits so as not to break the bootstrappability chain from the first open source release.
There are still some type issues, e.g., the preprocessor still treats all numbers as longs and doesn't understand the new type, and getting it to do so would not be entirely straightforward. But I bet this is good enough for most programs anyway...
Modifying #DesmetC's compiler front-end to support
unsigned long constants isn't going to be easy, given the sheer volume of places that assume all values fit in a long. I think I might squeak by, because constants carry some amount of pseudo-type information and an unsigned long doesn't take more space than a long, but it's still a bigger change than anything I've done so far.Someone asked me in the pull request comments how I'd generated thousands of test cases for #DesmetC, and I figured the #retrocomputing heads here in the fediverse might be interested in the answer, so I'm linking it here too: https://github.com/the-grue/OpenDC/pull/9#issuecomment-3866218702
I didn't put a lot of thought into the approach, and I'm sure it could be made much more elegant, but damn if it didn't flush out a lot of bugs.
Fix and regression-test integer arithmetic and comparison by PeterFidelman · Pull Request #9 · the-grue/OpenDC
Math operations now promote to int, unsigned, or long, in the C89 standards-compliant way ("usual arithmetic conversions"). Most notably, this removes the DeSmet-ism by which char additi...
The first round of test generation for #DesmetC is complete, yielding over 30,000 test cases for integer comparison, integer arithmetic, and constant folding. Numerous bugs dating to the late 1980s were found and corrected. This is now out for review as pull request 9.
I have discovered that the
>> operator in #DesmetC always performs logical right shift, never arithmetic right shift, even when the original type is signed. This seems to be undocumented.#DesmetC now has 10912 tests of its arithmetic and logical operations. This approach continues to turn up bugs, which I then fix.
