Activity for John Brandwood
-
John Brandwood posted a comment on ticket #196
Yes, certainly from my point of view.
-
The config.h is only needed for a seperate compilation that doesn't use SDCC's ".configure", such as when using Visual Studio and msbuild. If you're trying to build on linux or MacOS, or Windows with MSYS2, then you just need a simple build script to use SDCC's ".configure", with settings to tell it to look for include files in the sdcc/include directory. Here's one for a minimal SDCC build. You can play with the configuration options and see where/if/when it breaks. As for sdar, sdld, etc ... I...
-
The config.h is only needed for a seperate compilation that doesn't use SDCC's ".configure", such as when using Visual Studio and msbuild. If you're trying to build on linux or MacOS, or Windows with MSYS2, then you just need a simple build script to use SDCC's ".configure", with settings to tell it to look for include files in the sdcc/include directory. Here's one for a minimal SDCC build. You can play with the configuration options and see where if/when it breaks. As for sdar, sdld, etc ... I...
-
Treedec and Gala are just header libraries, there is nothing that you need to install to use them, they just go into the sdcc/include/ directory just like the boost headers. What you're going through with your ".configure", "make" and "make install" for these libraries is completely unnecessary if you want to use them locally, and don't wish/need to have them installed into your linux system. It is just like zlib, and libpng, and most other libraries. Yes, you can compile them into dynamically-linked...
-
Treedec and Gala are just header libraries, there is nothing that you need to install to use them, they just go into the sdcc/include/ directory just like the boost headers. What you're going through with your ".configure", "make" and "make install" for these libraries is completely unnecessary if you want to use them locally, and don't wish/need to have them installed into your linux system. It is just like zlib, and libpng, and most other libraries. Yes, you can compile them into dynamically-linked...
-
Boost was designed as a library of headers, there are no cpp files required, at least not for SDCC. If you pick entire Boost directories, then you lose the purpose of this list, which is the minimal set of files that SDCC actually uses. My purpose was not to set up a system that can download specific Boost files from the internet, it is to create a simple minimal "sdcc/include/" directory that can be added to the HuC repo and used to build SDCC. As such I do NOT want to chase every small change in...
-
Boost was designed as a library of headers, there are no cpp files required, at least not for SDCC. If you pick entire Boost directories, then you lose the purpose of this list, which is the minimal set of files that SDCC actually uses. My purpose was not to set up a system that can download specific Boost files from the internet, it is to create a simple minimal "sdcc/include/" directory that can be added to the HuC repo and used to build SDCC. As such I do NOT want to chase every small change in...
-
Here is what I have, please understand that this has only minimal cleanup for public use. This msbuild "solution" ONLY builds the SDCC compiler itself, and ONLY with the mos6502 port, so I don't think that most people would find it useful. Ger Hobbelt's patches in the PATCHES ticket are presumably closer to what you're looking for. Please note that this also includes a modification to SDCC's version.awk so that the version information is in one place (src/version.h) and not split into two directories...
-
Here is what I have, please understand that this has only minimal cleanup for public use. This msbuild "solution" ONLY builds the SDCC compiler itself, and ONLY with the mos6502 port, so I don't think that most people would find it useful. Ger Hobbelt's patches in the PATCHES ticket are presumably closer to what you're looking for. Please note that this also includes a modification to SDCC's version.awk so that the version information is in one place (src/version.h) and not split into two directories...
-
Thanks! Hahaha, yes, a small and independent codebase compilation is a worthy goal for most projects IMHO. ;-) One of the first things that I did was reducing the bloated 740MB Boost distribution, with 137MB of headers in nearly 15,700 files, down to an independent set of 11MB of headers in 2,100 files that SDCC actually requires to build on windows/linux/mac.
-
The differences between MCPP and Wave can be debated when I've updated MCPP for C23-compliance. MCPP has been unmaintained for years, just like Wave was, after all, there were minimal changes to the C preprocessor between C99 and C17! https://mcpp.sourceforge.net/
-
Hi Phillip, Giving time to work for free on "passion projects" is always difficult, and a blessing to those of us who take advantage of those other people's hard-work. I'm not complaining, but rather hoping to open a dialog to see if there is any (reasonable) help that I can provide, both by showing interest in the work that has been done, and perhaps in helping somewhat if that would be useful. But practically, I'm unlikely to ever get to even desire to have the deep knowledge of SDCC's internal...
-
Hi Benedickt, I was working on trying to get an SDCC 6502 port working back in 2016 with Erik Petrich's help, and even that long ago it was mentioned that this difficult task had been attempted multiple times before then. Gabriele has had much better results than I ever did, and quite frankly it's rather scary to look at SDCC's current mos6502 port code and see just how much knowledge of SDCC's internals I was lacking back then, and just how much work has been put in to get the 6502 port to where...
-
Hi Benedickt, I was working on trying to get an SDCC 6502 port working back in 2016 with Erik Petrich's help, and even that long ago it was mentioned that this difficulty task had been attempted multiple times before then. Gabriele has had much better results than I ever did, and quite frankly it's rather scary to look at SDCC's current mos6502 port code and see just how much knowledge of SDCC's internals I was lacking back then, and just how much work has been put in to get the 6502 port to where...
-
Please excuse the typo above, in spr_x(x) tmp is an "unsigned int" and not an "int", the code in the C file uses "unsigned int".
-
Code generaton for 6502 array access
-
Thank you! I'm currently building with both TREEDEC and GALA enabled.
-
Status of TREEDEC and GALA in the offical SDCC builds?
-
"Anyway, with these project files SDCC now compiles. " Hahaha ... we've both been doing the same work in trying to get SDCC to build with Visual Studio, but since I am only interested in getting the compiler itself to build, because I can build the rest in MSYS2, I didn't think that it was something that other people would be interested in. Anyway, thanks! :-) FWIW, I'll be raising an issue and sending a patch to the "gala" project, since that also needs a small fix for Visual Studio when compiling...
-
For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 04-gniibe-fix-12.patch I have applied a slightly modified version of that patch here ... https://github.com/jbrandwood/mcpp/commit/1d56f3287b20bb3876be1a0cc132e06dada5256b
-
For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 03-gniibe-fix-11.patch I have applied a slightly modified version of that patch here ... https://github.com/jbrandwood/mcpp/commit/f6f6e7363101e4fd948bea5626d6ba74efa45b73
-
For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 05-gniibe-fix-13.patch I have applied a slightly modified version of that patch here ... https://github.com/jbrandwood/mcpp/commit/70a33a47bbd34af32c58b4bb10bd82392a7836b3
-
FWIW, I have a similar ambivalence to SDCC's decision to use the GCC 12 pre-processor, and have looked at alternatives for my own use within an SDCC toolchain. Boost Wave is certainly one option for the SDCC developers to consider, but personally, I have decided to work on adding C23 support to Kiyoshi Matsui's MCPP (mcpp.sourceforge.net), another standalone C preprocessor project that has been unmaintained for a while and stuck at C99-compliance, but which is still used, and which is a current package...
-
This actually turned out to be nothing to do with a heap-use-after-free when debugging! It is caused by get_repl() corrupting the invocation of the 9th or 32nd macro parameter when it is used at the end of the replacement text, because it sees the encoded 0x09 or 0x20 formal parameter index as a trailing space to delete. That corruption then goes on to cause the undefined behavior which results in a segfault. I've checked-in a fix for this here ... https://github.com/jbrandwood/mcpp/commit/f1e1c...
-
This actually turned out to be nothing to do with a heap-use-after-free when debugging! It is caused by get_repl() corrupting the invocation of the 9th or 32nd macro parameter when it is used at the end of the replacement text, because it sees the encoded 0x09 or 0x20 formal parameter index as a trailing space to delete. That corruption then goes on to cause the undefined behavior which results in a segfault. I've checked-in a fix for this here ... https://github.com/jbrandwood/mcpp/commit/60752...
-
If it helps you, I have updated my personal fork of mcpp to autoconf 2.71 and automake 1.16 here ... https://github.com/jbrandwood/mcpp/commit/16313ef80e902677a1786f16c03479b6c6961ef9
-
FWIW, I've imported the SourceForge mcpp repo into github, applied the patches from the Fedora package (except for the Japanese html one, which breaks the file because it isn't actually encoded in UTF-8). I've also started to apply other fixes, including a commit for this gcc 14.x build problem. https://github.com/jbrandwood/mcpp/commit/3b274fe8f31d61996343b17402f30408a6e447cf Best wishes, John
-
FWIW, I've imported the SourceForge mcpp repo into github, applied the patches from the Fedora package (except for the Japanese html one, which breaks the file because it isn't actually encoded in UTF-8). I've also started to apply other fixes, including a commit one for this gcc 14.x build problem. https://github.com/jbrandwood/mcpp/commit/3b274fe8f31d61996343b17402f30408a6e447cf Best wishes, John
-
VS2019 warns about a potential misplaced ';' in SDCCgenconstprop.cc
-
It now appears that the IMA ADPCM reference implementation (linked in the above page) implements the math with rounding effects (errors?), while Sox adpcms.c avoid the rounding error. The problem is that the author of that wiki article, and the person who merged "ima_rw.c" and "vox.c" into "adpcms.c" are both wrong, and the IMA reference implmentation is correct, specificially because it is a reference implementation. The algorithm was originally designed to be implemented on cheap hardware using...
-
Bug in ucsim when compiled/run on Windows with msys2/mingw-w64
-
I've just checked the SoX source history in SoundForge and this bug was introduced...
-
Codec bug in IMA and OKI ADPCM algorithms.
-
It looks like MSYS2 is compiling zlib with _LARGEFILE64_SOURCE in order to generate...
-
OK, support for Brackets has been checked-in, and everything seems to work, except...
-
Looking into adding support for it ... but it doesn't seem to support multiple s...
-
Please feel free to ask any general questions here.
-
Oh ... just an FYI for anyone that does want to try my shell extension ... In order...
-
Well, I never got a reply back from Don Ho, so the initial project release does not...
-
Thanks for the pointer. The message is sent, just waiting for a reply.
-
I just had my email bounced back from "free dat fr" with "unknown user". Perhaps...
-
Hi, I've written an open-source collection of Windows Explorer shell extensions that...
1