> I pushed some changes based on your suggestions: That's great! I can confirm it is working. Robert
grischka via Tinycc-devel (2024-03-13 23:15): > On 11.03.2024 20:38, Robert Schlicht wrote: > > Yes, it is. But it’s really primitive, basically just a text editor that > has the compiler integrated, and calling it an IDE may be an exaggeration. > It’s the thing that is intended to make writing a “Hello, World!” program > (and slightly more interesting stuff) as painless as possible for beginners. > > But still really sleek, how it's "self-hosted", in a surprising way... > > I pushed some changes based on your suggestions: > https://repo.or.cz/tinycc.git/commitdiff/2b0a663df9236763c3967575e2c0fb89a9e58566 > > -- gr > > > > > Robert > > > > > > Jake Anderson (2024-03-11 15:10): > >> Is the IDE open source? An IDE that is packaged separately and uses the TCC > >> compiler could be useful. > >> > >> On Sun, Mar 10, 2024 at 1:01 PM Robert Schlicht <tin...@rschlicht.eu> > >> wrote: > >> > >>> At our university we offer a course where we program simple spatial > >>> simulations in various programming languages, one of them being C, for > >>> illustrating close-to-the-machine programming concepts. We here need a C > >>> implementation that is small (since it’s accessed over a network), works > >>> out of the box on Windows computers (since our students are beginners) and > >>> runs fast (so compiler errors are available instantaneously). We do not > >>> need advanced developer tools, and code running three times slower is > >>> acceptable because that is still faster than scripting languages. > >>> > >>> TCC is obviously a good option here, and for our course starting in April > >>> of this year, I put together a package https://rschlicht.eu/tc-ide.zip > >>> that includes a minimalist IDE running TCC and a very basic form of a C > >>> standard library, all contained in a standalone executable tc-ide.exe. The > >>> library is just headers that directly access the Windows API (no runtime > >>> needed) and should satisfy the requirements of a conforming freestanding > >>> implementation, while also including common memory, file, math and the > >>> printf family of functions. (If anyone finds this useful, I’ll gladly > >>> contribute it to the TCC project.) > >>> > >>> The executable is compiled by itself, although this currently requires a > >>> few hacks and workarounds to get it working as desired. I list these here > >>> as suggestions for improving TCC: > >>> > >>> (1) For using TCC as a library, it would be nice if it did a more thorough > >>> cleanup: > >>> – In a few places exit() is called in case of failure, but terminating the > >>> program is not very user-friendly; cleanly propagating failure or even > >>> some > >>> longjmp hacks might provide a better solution. [tc-ide does the latter, > >>> while patching function calls to keep track of memory and open files.] > >>> – Another problem I encountered is that TCC does not always properly > >>> restore the state of the global variables; compiling the following code > >>> fragment the first time produces an error message (as it should), but the > >>> second time it causes an exception (which I assume is a bug): > >>> void nothing(void) {for ( ; ; ) break;} void garbage(void) {switch > >>> [The workaround in tc-ide is ugly but straightforward: Make a copy of the > >>> memory block containing all global variables, and restore this block after > >>> TCC returns.] > >>> > >>> (2) I really appreciate that TCC can directly link to functions in Windows > >>> DLLs with no auxiliary .lib file and that it even supports directives like > >>> #pragma comment(lib,"kernel32"). The current implementation of the DLL > >>> lookup with a huge number of lseek & read calls (via read_mem() in > >>> tccpe.c) > >>> may be inefficient on some file systems. [tc-ide avoids this issue by > >>> creating file mappings in memory and redirecting lseek and read to those > >>> memory buffers, which it has to deal with anyway to access the embedded > >>> headers.] > >>> > >>> (3) The C23 preprocessor directive #embed would be of help for embedding > >>> headers and other files as byte arrays in the program. [tc-ide currently > >>> does this by providing a non-standard feature with a custom notation like > >>> #include "stdlib.h#".] > >>> > >>> (4) TCC uses fixed buffer sizes for file paths in certain places. For > >>> example, libtcc.c has 260(=MAX_PATH) in config_tccdir_w32() and > >>> _fullpath(), 1000 in tcc_add_systemdir() and 1024 in > >>> tcc_add_library_internal(), while tccelf.c has 1024 in getcwd(). Windows > >>> has been supporting long file paths for quite a while now, so it might be > >>> better to allocate those buffers dynamically: > >>> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation > >>> > >>> (5) Some rarely used C library functions could perhaps be replaced to make > >>> the code less dependent on such features. Examples are the single use of > >>> alloca() in libtcc.c to set up a buffer and the use of scanf() in tccpp.c > >>> to convert the TCC version string into a number. [tc-ide here provides > >>> stubs.] > >>> > >>> (6) It would be useful to allow the user to set the entry point symbol > >>> (either the one called by the OS or the one called by the startup code), > >>> like other compilers do. [tc-ide provides its own version of _start(), > >>> which simply calls main().] > >>> > >>> (7) Additional observations: > >>> – In tcc_new() (tcclib.c), checking the return value of tcc_mallocz is > >>> probably redundant. > >>> – In tcc_close() (tcclib.c), I do not understand why the test is ">0" > >>> instead of ">=0". Typically 0 is stdin, but maybe the code should not rely > >>> on that. > >>> – The protection of InitializeCriticalSection() in tcc.h is not > >>> thread-safe and can lead to a race condition. > >>> – In Windows, the semicolon ';' can appear in file names and is therefore > >>> perhaps not an ideal PATHSEP path separator character (despite that fact > >>> that it is still used in that function in the Path environment variable); > >>> a > >>> double null-terminated string could be a better choice. > >>> > >>> Let me conclude with a question on the licenses. As I understand it, TCC > >>> is licensed under LGPL, although there is also a more permissive > >>> RELICENSING statement, but I assume this is irrelevant due to the various > >>> contributions by authors not listed there. Is that so, or am I missing > >>> something? > >>> > >>> Robert > >>> > >>> _______________________________________________ > >>> Tinycc-devel mailing list > >>> Tinycc-devel@nongnu.org > >>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel > >>> > > > > _______________________________________________ > > Tinycc-devel mailing list > > Tinycc-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
