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
