On 03.03.2024 21:26, Eric Raible wrote:
> isn't there a garbage collecting done at the end to remove all the unused
stuff
> to produce a binary that contains only the necessary parts ?
That very well might be the case, but given that tcc_get_symbol()
can be used at any time between tcc_relocate() and tcc_delete(),
it follows that _at least_ symbols are resident in the TCCState.
What I'm wondering about is the feasibility of keeping just code and
data, and flushing everything else. This would require a new API -
something like tcc_finalize(TCCState *) or perhaps
tcc_finalize(TCCState *, flags), where flags specify what to flush.
Me thinks this discussion is going around in circles.
Your tcc_finalize() subject of obsession was what we already had
all the time since 0.9.25, that is the option to allocate the
executable code separately from the state and therefor the option
to delete (finalize) the state and still keep the code.
It just happened that at some point people found that tcc not only
should allow them to have the cake for their own, but that they
also want tcc to provision them with some extra convenience to
cleanup with it (including unprotect and release of the unwind
table on win64).
At which point I found that maintaining two options for running
code might not be to the best for both sides, neither for tcc wrt.
maintainability nor for users wrt. avoidance of inconvenience.
Of course now that we have that simpler API, it was clear that
soon someone would come up suspecting some benefit if it were not
only simple but complicated too, optionally of course.
Where simple plus complicated is more complicated than just
complicated btw.
And while it's completely unclear what such benefit could be,
under what scenario.
I don't know enough about the internals, but if I'm willing to run with
CONFIG_RUNMEM_RO, it seems like the per TCCState memory use in my case
could be decreased from something like 29K to 1K or 2K.
I should mention that the memory usage in my case is 29K regardless
of whether CONFIG_RUNMEM_RO is 0 or 1.
How do you know this?
Some output from tcc -nostlib -vv -bench -run test.c
(tcc compiled with -DMEM_DEBUG -DCONFIG_RUNMEM_RO=0)
int x = 1; //.data
int y; // .bss
const int z; // .rdata
int _start() { return 0; } //.text
tcc version 0.9.28rc 2024-03-04 mob@d4f7fcbb* (i386 Windows)
-> test.c
-----------------------------------------------------
memory 007B6390 len 02000
-----------------------------------------------------
0: .text 007B7000 len 00018 align 1000
1: .rdata 007B7040 len 00004 align 0040
2: .data 007B7044 len 00004 align 0004
2: .bss 007B7048 len 00004 align 0004
-----------------------------------------------------
protect rwx 007B7000 len 01000
-----------------------------------------------------
# 1074 idents, 6980 lines, 137488 bytes
# 0.001 s, 6980000 lines/s, 137.5 MB/s
# text 17, data.rw 4, data.ro 4, bss 4 bytes
# memory usage: 10250 bytes (8192 to run, 499 for 14 symbols, 1559 for state
etc)
Which is 8kB to run and 2kB extra.
Same for -run tcc.c
-----------------------------------------------------
memory 00E159D8 len 63000
-----------------------------------------------------
0: .text 00E16000 len 43418 align 1000
1: .rdata 00E59440 len 08c00 align 0040
2: .data 00E62040 len 00311 align 0004
2: .bss 00E62358 len 15938 align 0008
-----------------------------------------------------
protect rwx 00E16000 len 44000
-----------------------------------------------------
# 29262 idents, 99132 lines, 3377368 bytes
# 0.202 s, 490752 lines/s, 16.7 MB/s
# text 270677, data.rw 4, data.ro 35789, bss 88112 bytes
# memory usage: 413204 bytes (405504 to run, 6030 for 158 symbols, 1670 for
state etc)
Where the 4 bytes initialized data.rw btw. is Eric Raible's
static void *(*reallocator)(void*, unsigned long) = default_reallocator;
-- gr
Thanks - Eric
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
