Re: [Tinycc-devel] Added virtual io to tinycc
You've got the idea and the possibilities it allow.
As you can see I've tried a balance between simplicity and functionality,
and found that with a small change on int fds to struct fds I could
achieve what I was looking at first place with minimal complications.
On Mon, Jan 14, 2013 at 2:54 AM, Jared Maddox absinthdr...@gmail.comwrote:
Date: Sat, 12 Jan 2013 23:33:48 +0100
From: grischka gris...@gmx.de
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Added virtual io to tinycc
Message-ID: 50f1e4cc.6000...@gmx.de
Content-Type: text/plain; charset=UTF-8; format=flowed
Domingo Alvarez Duarte wrote:
Let's see if I can explain it better.
The modifications I did was replace:
fd - fd or fd-fd depending on the context
[...]
Indeed switching tinycc to cope with struct fd was a bad decision
to begin with. Under any circumstances I'd recommend to switch your
wrappers to int fd instead and thus to the same prototypes as
the original functions. Not a big deal, really.
And the question (or suggestion, if you prefer) still is:
Can you make this work with all your extra files put in a
subdirectory
contrib/choose your name
and with only the most minimal required change to our existing
files?
I suppose it could be three lines such as
#ifdef TCC_CONTRIB_WHATEVER
# include contrib/whatever/some.h
#endif
or maybe even less.
--- grischka
I think that Domingo sees that as a problem because his modification
doesn't currently use the same function prototypes. By switching the
fds to ints that correspond to an element in an array or tree (I can
donate a tree implementation if desired, though the balancing is still
off) it should be possible to mostly use the same prototypes. However,
there may be some reason why he's giving extra arguments to open
(perhaps he wants to enable TCCState-level customizations), so there
would be at least one prototype change regardless.
Though, honestly, it should be possible to do a five line
conventional-input converter if the int fd change goes through, so I
think that it makes sense. The change will definitely affect all of
the file i/o calls, but only by one added argument, and changing all
of the struct fds to ints.
Now on to the actual capability. Note that what I'm suggesting WOULD
belong in something like contrib/virtual_fs/vfs.h. From my
perspective a full file and mount system should be provided by
anything like this. I won't say that it's zero-effort, but it isn't
too bad either. Basically you take a virtual filesystem (I can
describe how this sort of thing works if you need some help with it:
I've looked at writing them before), extend it's file/folder structure
to support overrides (thereby allowing you to mount another virtual
filesystem at arbitrary points without un-linking the previous data
there), and if you just don't find a file or folder then the code
resorts to the fallback that the current virtual filesystem
structure is configured with (which could be yet another virtual
filesystem or a file not found error). If you want access to the
real filesystem then you just write an appropriate wrapper and mount
it in the right place. If you want to overlay a real or a virtual
filesystem on each other then you decide which you prefer to get your
files from, and set the other as the fallback. Here's an example of
how the structures might look:
typedef struct vfs vfs;
typedef struct vnode vnode;
struct vfs {
size_t elements;
char **names;
vnode *nodes;
vfs *fallback;
/* You might try int (*node_open)( void*, const char**, int, vfs** ),
for a recursion-free try again style. */
int (*node_open)( void*, const char*, int );
};
struct vnode {
enum {
vnode_file = 1,
vnode_directory = 2
} type;
vfs *dirmount;
void *nodemount_data; int (*nodemount_open)( void*, const char*, int );
void *node_data;
};
The main nuisance is that searching for the right file will be slow.
If you want speed AND flexibility, then you want to write a
string-table implementation so that your file/folder searches go
faster. Really, most of the complexity is in making it go faster, not
in making it work.
___
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
Re: [Tinycc-devel] Added virtual io to tinycc
Le lundi 14 janvier 2013 03:54:27, Jared Maddox a écrit : [SNIP] The main nuisance is that searching for the right file will be slow. If you want speed AND flexibility, then you want to write a string-table implementation so that your file/folder searches go faster. Really, most of the complexity is in making it go faster, not in making it work. Given one of the key feature of tcc is its speed, that looks like an important thing to improve. Also, we are trying to stabilize tcc in order to make a new release (see [1]) so it would be nice if this could avoid as much as possible to touch the current code. I would personally have preferred that this commit is reverted for now and reapplyied just after the release (should be a question 1-2 weeks I hope). Don't take me wrong, contributions are very much welcome, this one included. I'm just saying the commit is not made at the best time :) [1] http://lists.nongnu.org/archive/html/tinycc-devel/2013-01/msg5.html Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Added virtual io to tinycc
Thomas Preud'homme wrote: Also, we are trying to stabilize tcc in order to make a new release (see [1]) so it would be nice if this could avoid as much as possible to touch the current code. I would personally have preferred that this commit is reverted for now ... I agree. ... and reapplyied just after the release I would not bother. It goes without saying that there are many interesting things you can do with tinycc, which includes hacking the sources in any way, pasting code snippets, plugging in modules, whatever. And our share to support that is to keep tinycc tiny! So we should say Thanks, nice., revert, and people can still try the patch with: git checkout -b vio 2358b378b3cd526956713f033f5a0ecaa5f63951 Same with the vswap commit IMO. Good catch of Kirill with the CPU costs, but the patch has issues and anyway is just too ugly, in this form. Thanks, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 17:03:28, grischka a écrit : Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae 0eaf6d8d The headers from include are copied to win32/include during install I'm not sure to understand why _STATIC_ASSERT was modified. Are you just claiming the fix is subobptimal because of the code duplication or the fix is useless? - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5ab ee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. Indeed. I followed the chain of changes when I noticed that patch and it led to your commit f366cb20fe06396609a5438756c3c49662b7316c. However, I didn't read into details the content of the for loops at that time. I just assumed a bug was noticed by someone and that was the fix. Now, I see the if (0 == *p) and realize it was indeed intentional. Reverted. signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Hi Akim, Le dimanche 13 janvier 2013 23:30:49, Thomas Preud'homme a écrit : In the case we had some warnings I'd still prefer to not use -D_FORTIFY_SOURCE 0. The first reason is that _FORTIFY_SOURCE does 2 things: it hardens the source by adding some buffer overflow checks and it adds more warnings. Setting _FORTIFY_SOURCE to 0 would stop the warning but also stop all the hardening which could be wanted. Secondly, turning off warnings globally to avoid some false positives would mean we miss real cases where someone forgot to test the return value of a function. Also, someone please test the functionality of the install. (I suspect libtcc.h might be missing). Good catch. It seems it comes from commit e79281f58ec302e8cc9dfc7d00e06f426fcd2acd. Can you explain me what is the purpose of second part of the sed command used to create symlink to Makefile: s,[^/]*/,../,g I'm trying to build from tmp/tcc-builddir while the source are in tmp/tcc. The first part of the sed command correctly transform ../tcc/./ into ../tcc/ but then the second part change it into ../../ I suppose that was not the intended behavior but I don't see what was expected. Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le 14 janv. 2013 à 17:55, Thomas Preud'homme robo...@celest.fr a écrit : Hi Akim, Hi Thomas, If there were other messages for me, I might have missed them :( Can you explain me what is the purpose of second part of the sed command used to create symlink to Makefile: s,[^/]*/,../,g The thing is that cp 1/2 3/4/ and ln 1/2 3/4/ have nothing in common: in the ln case, it is equivalent to cd 3/4 ln 1/2 .. Absolute paths are resolved from the destination, not from the current directory. So if I mean to ln 1/2 3/4/ in the way cp does, I need to ln ../../1/2 3/4/. I'm trying to build from tmp/tcc-builddir while the source are in tmp/tcc. The first part of the sed command correctly transform ../tcc/./ into ../tcc/ but then the second part change it into ../../ I suppose that was not the intended behavior but I don't see what was expected. This is the kind of things that Autoconf provides bullet proof :( I don't know why there is the trailing ./, I guess it should suffice to cleanup the directories first, i.e., removing things like ./. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le lundi 14 janvier 2013 18:01:08, Akim Demaille a écrit : Le 14 janv. 2013 à 17:55, Thomas Preud'homme robo...@celest.fr a écrit : Hi Akim, Hi Thomas, If there were other messages for me, I might have missed them :( Can you explain me what is the purpose of second part of the sed command used to create symlink to Makefile: s,[^/]*/,../,g The thing is that cp 1/2 3/4/ and ln 1/2 3/4/ have nothing in common: in the ln case, it is equivalent to cd 3/4 ln 1/2 .. Absolute paths are resolved from the destination, not from the current directory. So if I mean to ln 1/2 3/4/ in the way cp does, I need to ln ../../1/2 3/4/. I'm trying to build from tmp/tcc-builddir while the source are in tmp/tcc. The first part of the sed command correctly transform ../tcc/./ into ../tcc/ but then the second part change it into ../../ I suppose that was not the intended behavior but I don't see what was expected. This is the kind of things that Autoconf provides bullet proof :( I don't know why there is the trailing ./, I guess it should suffice to cleanup the directories first, i.e., removing things like ./. What do you think of the proposed fix? It works for me at least. It first look at the directory in which the symlink is to be done and strip entirely the path if it's ./. Else, it will look like path/to/symlink and it will replace each subdirectory by .., as in your original patch. At this stage you get the correct number of .. to go down from the directory where a given symlink is to be created to the directory in which configure was called. You just need to add the relative path to the source root + the path to the Makefile needing to be symlinked. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas Preud'homme wrote: Le dimanche 6 janvier 2013 17:03:28, grischka a écrit : Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae 0eaf6d8d The headers from include are copied to win32/include during install I'm not sure to understand why _STATIC_ASSERT was modified. Are you just claiming the fix is subobptimal because of the code duplication or the fix is useless? Done. The code duplication was wrong. The _STATIC_ASSERT fix looks ok. It was to compile the vswap patch. Reverted that too (leaving a comment in the source). --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le 14 janv. 2013 à 18:23, Thomas Preud'homme robo...@celest.fr a écrit : What do you think of the proposed fix? It works for me at least. It first look at the directory in which the symlink is to be done and strip entirely the path if it's ./. Else, it will look like path/to/symlink and it will replace each subdirectory by .., as in your original patch. yes, this is what I meant by cleaning. At this stage you get the correct number of .. to go down from the directory where a given symlink is to be created to the directory in which configure was called. You just need to add the relative path to the source root + the path to the Makefile needing to be symlinked. This part is expected to be correct in what I had submitted. IIRC, only the cleanup part is needed, right? You might have intended to attach a patch for review :) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le lundi 14 janvier 2013 18:47:12, Akim Demaille a écrit : Le 14 janv. 2013 à 18:23, Thomas Preud'homme robo...@celest.fr a écrit : What do you think of the proposed fix? It works for me at least. It first look at the directory in which the symlink is to be done and strip entirely the path if it's ./. Else, it will look like path/to/symlink and it will replace each subdirectory by .., as in your original patch. yes, this is what I meant by cleaning. At this stage you get the correct number of .. to go down from the directory where a given symlink is to be created to the directory in which configure was called. You just need to add the relative path to the source root + the path to the Makefile needing to be symlinked. This part is expected to be correct in what I had submitted. IIRC, only the cleanup part is needed, right? You might have intended to attach a patch for review :) Yes, only the cleanup was needed but it was easier (at least it seemed easier to me) to build the path differently, hence this last part changed as well, but the principle remain the same. You can find the patch in the web VCS interface at: http://repo.or.cz/w/tinycc.git/commitdiff/f7b417723ed6875684b3591845e93ae1f49813d3?hp=a4e630c7d94f64af160ffaabf290735b7374c8ec signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Akim Demaille wrote: This is the kind of things that Autoconf provides bullet proof :( Maybe it does something but there is no way to know how. And so we prefer transparency over bullets, nowadays. ;) --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Revert Optimize vswap()
On Sun, Jan 06, 2013 at 05:03:28PM +0100, grischka wrote: [...] Compilation on Windows with MSC fails in tccgen.c:vswap(): ../tccgen.c(476) : error C2143: syntax error : missing ';' before 'type' [more ...] After moving declarations before statements, it fails like this: ../tccgen.c(490) : warning C4308: negative integral constant converted to unsigned type ../tccgen.c(490) : warning C4307: '*' : integral constant overflow ../tccgen.c(490) : warning C4307: '+' : integral constant overflow ../tccgen.c:481: error: incompatible types for redefinition of '__static_assert_t' [more ...] grischka! Could you please Cc relevant people when talking about reverting their patches? I was unaware of this issue until recently. Some of us read lists in batches through gmane... I'd suggest to move that optimization into its own function void memswap(void *p1, void *p2, size_t n); For it to work effectively that memswap should be static inline and contains test for n to be builtin constant and be more ugly in your speak, and also that __builtin_constant() tests might not work out of the box in tcc... or otherwise to revert it. Maybe let's just do it step by step and fix _STATIC_ASSERT for win32? Especially there is already one in win32/include/malloc.h:#define _STATIC_ASSERT(expr) extern void __static_assert_t(int [(expr)?1:-1]) #ifndef _MSVC # define _STATIC_ASSERT // from ccan #else # define _STATIC_ASSERT // for msvc #endif ? Optimizing vswap() was an easy win and given tinycc goal is to be fast compiler I suggest not to revert it. On the other hand I have no microsoft compilers installation nor any windows on my machines, and thus can't test how the code works/breaks there. That _STATIC_ASSERT was taken from CCAN[1] which is valuable and quality library for C. No offences, but ruling out speedups on msvc non-standartness is not wise imho. I'm open to fixing it, just please cc me, and please provide advices with msvc. Thanks, Kirill [1] http://ccodearchive.net/ ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Revert Optimize vswap()
2013/1/15 Kirill Smelkov k...@navytux.spb.ru: On Sun, Jan 06, 2013 at 05:03:28PM +0100, grischka wrote: [...] Compilation on Windows with MSC fails in tccgen.c:vswap(): ../tccgen.c(476) : error C2143: syntax error : missing ';' before 'type' [more ...] After moving declarations before statements, it fails like this: ../tccgen.c(490) : warning C4308: negative integral constant converted to unsigned type ../tccgen.c(490) : warning C4307: '*' : integral constant overflow ../tccgen.c(490) : warning C4307: '+' : integral constant overflow ../tccgen.c:481: error: incompatible types for redefinition of '__static_assert_t' [more ...] grischka! Could you please Cc relevant people when talking about reverting their patches? I was unaware of this issue until recently. Some of us read lists in batches through gmane... I'd suggest to move that optimization into its own function void memswap(void *p1, void *p2, size_t n); For it to work effectively that memswap should be static inline and contains test for n to be builtin constant and be more ugly in your speak, and also that __builtin_constant() tests might not work out of the box in tcc... or otherwise to revert it. Maybe let's just do it step by step and fix _STATIC_ASSERT for win32? Especially there is already one in win32/include/malloc.h:#define _STATIC_ASSERT(expr) extern void __static_assert_t(int [(expr)?1:-1]) #ifndef _MSVC # define _STATIC_ASSERT // from ccan #else # define _STATIC_ASSERT // for msvc #endif ? Maybe we can just fully port _STATIC_ASSERT changes from mingw-w64 changeset 4293? http://sourceforge.net/apps/trac/mingw-w64/changeset/4293 Optimizing vswap() was an easy win and given tinycc goal is to be fast compiler I suggest not to revert it. On the other hand I have no microsoft compilers installation nor any windows on my machines, and thus can't test how the code works/breaks there. That _STATIC_ASSERT was taken from CCAN[1] which is valuable and quality library for C. No offences, but ruling out speedups on msvc non-standartness is not wise imho. I'm open to fixing it, just please cc me, and please provide advices with msvc. Thanks, Kirill [1] http://ccodearchive.net/ ___ 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
