It took me a while to understand your post, I've been up all night debugging. And I've isolated my bug...
Anyway, I see what you did, and it's cool, but it doesn't match my use-case which is for built in compiler, they call them "jits" these days, although what I want isn't technically a jit. I mean more of a system where you can keep adding code even as the old code is still running, the sort of thing that used to be more popular with languages like Lisp, or Smalltalk or Forth. That's not called a jits generally let programs be interpreted for a while and then compile code while it's running. These old languages compiled code as soon as it was entered, it's just that you could add code without deleting the data that was already there, and in the case of the more interactive systems, you could even have some of the code already running while you're adding to it. And there wasn't an inherent distinction between the development environment or even the windowing system and the user's code. I once saw someone change how selected text is rendered in a Smalltalk system by changing the editor's code from within the editor. That's the sort of system where you don't want all your source code concatenated and compiled at once like you're doing, you want to compile a bunch of tiny routines and have them access each other. Actually I can see there's a problem with the run time system in that case, because you want routines to share run time code that's already sitting in memory, not link to a new run time system each time. C isn't designed for that. I asked about that before and didn't get an answer, probably because what I was imagining is so foreign to how C works. C isn't designed to link to a run time system once, and then slowly add more routines to a live system, reusing the symbol table for the existing run time and the already compiled routines. I guess I'm going to have to replace the runtime code with stubs that share. But I can see a use for some of what you're doing, concatenating header files and doing any preprocessing on them only once. A kind of not very sophisticated precompiled header. Josh Scholar On Thu, Dec 24, 2020 at 7:39 AM Kyryl Melekhin <[email protected]> wrote: > >I figured a lot of people would like, that >libtcc can hold a virtual > read-only file >system, so that you don't actually need to >have an > include, lib and libtcc directory for >a project to use libtcc. > > Is that so? I can kind of see where you are coming from, but this is not > the right way to solve it. It creates unnecessary dependency bloat, and > even a lot more headache for anybody willing to take time and read though > that. If you want I can send you my custom amalgamated version of TCC which > is literally 1 c file, does not depend on tcclib, because it has it in it's > source already, all the assembly routines for stuff like alloca, are > written in extended asm syntax and they work. There is no need to run make > to compile, just gcc tinycc.c and some platform flags is enough. You also > don't need to worry about header files, because you can always make your > own, just write extern printf(...) bla bla and it will work. That's > basically how I use tcc, it's so much easier to work with and maintain > especially now that i have wrote a special version of tcc which can > correctly amalgamate any C source code just like compiler sees it, no > assumptions because tcc implements complete preprocessor spec. > > On Thu, Dec 24, 2020, 06:29 Joshua Scholar <[email protected]> > wrote: > >> If anyone who knows this project better than me can help it would be >> wonderful. >> >> I decided to add a feature I figured a lot of people would like, that >> libtcc can hold a virtual read-only file system, so that you don't actually >> need to have an include, lib and libtcc directory for a project to use >> libtcc. >> >> Warning, I'm a windows user, so I'm probably doing this on a different >> system than most of you. >> >> Now that I think about it, my choice to do it by embedding a zip file and >> linking miniunzip and libz in was probably a poor one for efficiency. >> Those parts are working, so I'll leave it alone until I get the bugs I >> caused out, unzipping, buffering the unzipped data every time, allocating >> and deallocating the memory for those buffers and putting a global lock on >> the miniunzip calls waste time, and if people want to use libtcc as >> something like a jit, they probably would prefer the speed to the memory. >> >> Also, and even more convincing, embedding libz and the latest version of >> minizip (which has forked off from libz) into the project and making it >> work on every platform would be a nightmare. >> >> But never mind that for now, my current state is: >> tcc works for making .o files and .a files and the results are byte >> equivalent the previous version - and it doesn't need the directories to >> exist to do it. >> >> But libtcc_test silently fails, and I can't get this version of tcc to >> make exe files and -run doesn't work. >> >> But since I didn't make a visual studio solution file, I'm just working >> off the command line, I haven't been able to use a debugger and I'm lost >> for why everything compiles without complaint and runs without complaint, >> but not everything works. >> >> To get help from the compiler I replaced the int type for posix handles >> with a struct type for a wrapped handle that can read from this virtual >> file system. Since the types can't be substituted without error, I should >> have caught all the spots where I need to change things. >> >> Joshua Scholar >> _______________________________________________ >> Tinycc-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel >> > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
