Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Non-sucking Win32 C compiler

Name: Anonymous 2009-08-12 14:37

I need a small (not bloated to hell, clean, not system ruining / service installing) compiler for tiny C programs with POSIX-like semantics (i.e. C library that doesn't suck and stuff like read() instead of ReadFileWEX(WHANDLE, WSHARINGMODE, WSECURITYCONTEXT, NULL, NULL, NULL, NULL) - true POSIX stuff like fork() et al is not needed).

Visual Studio or cygwin are out of the question. Some GCC distro like mingw might be OK depending on how much the installation sucks (ideally there wouldn't be any installation at all).

Any ideas or do I give up to ENTERPRISE-quality software?

Name: Anonymous 2009-08-15 20:07

>>58
i can't stop lolling.
YOU are interested in code optimization? hahahahaha.
bullshit. you write the most inefficient code i've ever seen.
for example, i've seen you write something very similar to this:
for(; i < (strlen(str1) > strlen(str2)? strlen(str2): strlen(str1)); ++i)
   str1[i] == str2[i];

your code is truly laughable, and this little snippet is just the tip of the iceberg.
what makes it even funnier is that you're completely dokyun

Name: Anonymous 2009-08-15 21:10

>>60
You do realize that because of this he stands to gain the most out of nearly any programmer from optimization right? Will an optimizing compiler move strlen calls outside the loop invariant? Yes. Will it memoize the strlen calls, or even just the comparison result? Yes. That is of course, if it can determine the loop body doesn't change the result of the strlen calls, and I would put money on that being the case for any non-shit compiler (assuming the == was meant to be =).

Name: Anonymous 2009-08-15 21:28

>>61
Another person who thinks optimising compilers are magic wands. Prepare to lose that money.

It doesn't matter, anyway, since FV thinks TCC is an optimising compiler.

Name: Anonymous 2009-08-15 21:45

>>62
I have personally tested this optimization on gcc in the past. If you are invoking the standard strlen function, gcc knows beforehand that it is pure. Figuring out that the null terminator in str1 will never get overwritten then should be trivial.

Name: Anonymous 2009-08-15 21:56

>>61
no.
how does the compiler know that the functions don't increment a static variable or somesuch and need to be called every iteration?
it doesn't.
compilers are not magic

Name: Anonymous 2009-08-15 22:02

Just download the window SDK.  It's almost a fucking xcopy for an install.. It supports POSIX api's (like just about every version from NT4).  And it builds Win32 code as you are, for some reason, asking for.

Oh.. and Posix is _Open,  OpenFile(..) is Win16 and CreateFile(..) is Win32.  The difference is about 2 parameters and CreateFile gives you a useful Win32 handle.

Learn about what you're writing before you actually start (facepalm).

Name: Anonymous 2009-08-15 22:07

>>63
It can know that strlen is pure and use that for some optimisations, but it won't step through your code to the extent required to turn the code in >>60 into non-sucking code. Rather than being ``trivial'', the sort of optimisations you have in mind are equivalent to solving the halting problem.

If it did do something like that for you, chances are you were in one of the rare situations were a C string was actually immutable (and I don't mean const char*). That's not the case in >>60.

Name: Anonymous 2009-08-15 22:40

>>66
You completely misunderstand both the halting problem and this one. The difference here is that the compiler has a higher order view of the inner workings of whatever you give it. It does not have some magical black box and has to return 1 or 0 based on whether the black box halts on given input or not. It can analyze inside the black box and determine for itself.

compiler: is strlen pure? yes
compiler: will str1[i] = str2[i] ever change the invariant?
compiler: will "i" ever exceed the length of str1?
compiler: no, the invariant is bounded above by strlen(str1)
compiler: therefore str1[i] = str2[i] will never overwrite the null terminator
compiler: therefore neither strlen changes
compiler: the loop invariant must never change
compiler: i can optimize this out

Find where the halting problem is solved please.

Name: Anonymous 2009-08-15 22:57

>>67
What happens when str1 or str2 are in shared memory?

The point isn't even that you can tailor-make a compiler to deal with a specific piece of shared code; that's plainly obvious and completely irrelevant.

Name: Anonymous 2009-08-15 23:02

>>66
It can know that strlen is pure and use that for some optimisations
Yanno, I wish C was better about letting you write explicitly pure functions (and forcing them to actually be pure). I heard Ada does this with the function vs. procedure keywords, and if you use the former you can't modify anything outside of local scope.

Name: Anonymous 2009-08-15 23:22

>>68
It doesn't matter if they are in shared memory, the compiler has already determined no null terminator will get written so it doesn't really change anything, it's hardly tailor made.

Name: Anonymous 2009-08-15 23:49

>>70
If your ``optimization'' changes what an algorithm actually does, it's not an optimization. Nor is it something any compilers will actually do.

Name: Anonymous 2009-08-15 23:49

>>70
What? What if you put a null-terminator before the current one?

Name: Anonymous 2009-08-16 0:48

nomatter what strlen optimisations are offered by the compiler, there is still the plain fact that the code could easily be written without calls to strlen.
allow me to demonstrate. something like this would be much more efficient:
while(*str1 && *str2)
   *str1++ = *str2++;

Name: Anonymous 2009-08-16 1:52

>>73
while(*str1++ = *str2++);

Name: Anonymous 2009-08-16 2:24

>>74
buffer overflow if str1 was smaller than str2.

Name: Anonymous 2009-08-16 2:24

>>75
Minor side effect.

Name: Anonymous 2009-08-16 2:40

while (*str1 && *str1 = *str2); should be kosher.

Name: Anonymous 2009-08-16 2:49

>>77
infinite loop if neither string is empty.

Name: Anonymous 2009-08-16 2:50

(assuming you put in the parentheses so it even compiles)

Name: Anonymous 2009-08-16 2:56

>>78
What's that even supposed to mean?

Name: Anonymous 2009-08-16 3:03

>>78
Well, obviously I forgot the ++, didn't I? Don't be dense.

>>79
It's odd that the parser can't make sense of that, since there's really only one way to parse that so that you end up with an assignment to an lvalue.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List