Batch malloc
in [General Programming]
|
Prev: hacking
Next: How get percentage of use of cpu
From: BGB / cr88192 on 18 Jan 2010 13:58 "bartc" <bartc(a)freeuk.com> wrote in message news:p2%4n.28010$Ym4.5278(a)text.news.virginmedia.com... > BGB / cr88192 wrote: > >> meanwhile, I am off trying to find a way to get my C compile times >> maybe 10 or 100x faster by making headers optionally optional... >> (IOW: optionally switching to a very different scoping model...). > > Some of my first compiler attempts used (for good reasons) a > memory-resident program, a sort of combined editor/compiler/runner. > > This way, symbol tables stayed resident and were reused on the next > compilation. You just needed a way of clearing the tables relevant to the > module being compiled but keeping header-related ones. This wasn't C so > header stuff was in a higher scope, which helped. > yeah. C has the big issue of, semantically, expecting that large amounts of headers be used, be all inlined into a big buffer, parsed, ... having a large amount of content (say, 500kB-1MB) of stuff pulled in from headers, has a way of bogging down the parser... > (However if you're talking about your compiler system which, iirc, writes > and rereads XML representations between passes, you might want to look at > some obvious speed-ups first...) > I used the profiler before, and from the profiler determined that lots of time was going into the C parser's tokenizer, and as well, the functions for decoding UTF-8 characters. a few hacks sped these up. now, in the metadata-DB tool (a variant of the compiler), it seems adding keys to the database is a big user of time, but there is not much obvious way to speed this up. not spewing out an XML dump can also speed things up some, but it seem numerically to not be all that significant (vs preprocessing and parsing, which seem to be the big time-eaters). however, there is a simple and good way to pull off a 100x speedup: processing 100x less data... reducing times from, say, 750-1500ms, to 7.5-15ms, would be a good deal of an improvement... then, 'eval' might actually be usably fast... > -- > Bartc
From: Rod Pemberton on 19 Jan 2010 04:21 "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message news:hj28p7$na4$1(a)news.albasani.net... > > malloc is a function, and not a keyword. True... But, that's an entirely different topic: for(), while(), return(), switch(), sizeof() could all be implemented as functions. It might even be possible to do it an be compliant. The compiler must recognize them as being keywords or operators for proper parsing, but the implementation could use functions to implement them. > malloc is a function, and not a keyword. I just meant that to recognize malloc without the header, you're parser will need to recognize it as some language element, say function or keyword, when it wouldn't normally do so, since it's header hasn't been included. > #define _noinclude //magic define that enables this "magic"... Nice. You're just going copy them into your tables/trees as functions as the compiler would've done with the actual include...? Should work well, IMO. Ignore my statements on malloc... > granted, there are certain "compiler built-in functions" (such as sin, cos, > ...) but these are different... There's no reason why malloc() and free() couldn't have been part of the C language instead of in the C libraries. It would've made C a better language, IMO. It's just random history that they aren't. Rod Pemberton
From: bartc on 19 Jan 2010 04:59 "Rod Pemberton" <do_not_have(a)havenone.cmm> wrote in message news:hj3tk9$vbf$1(a)speranza.aioe.org... > "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message > news:hj28p7$na4$1(a)news.albasani.net... >> >> malloc is a function, and not a keyword. > > True... But, that's an entirely different topic: > > for(), while(), return(), switch(), sizeof() could all be implemented as > functions. It might even be possible to do it an be compliant. Difficult I think. How do you pass the block of code forming the main part of for() and while(), which needs to be evaluated many times? How do you return from a function implementing return? Or evaluate sizeof() which must be a compile-time value? Or allow goto into and out of the statements? Or access the local variables of the surrounding code? > The > compiler must recognize them as being keywords or operators for proper > parsing, but the implementation could use functions to implement them. In other words, as it usually works now, and not caring about the implementation details. > There's no reason why malloc() and free() couldn't have been part of the C > language instead of in the C libraries. It would've made C a better > language, IMO. It's just random history that they aren't. I think many standard C functions are already recognised as special, and as part of the language, in order for the compiler to do it's job well. If you really wanted to make C better, there's already quite a big list... -- Bartc
From: Rod Pemberton on 19 Jan 2010 07:08 "bartc" <bartc(a)freeuk.com> wrote in message news:pof5n.28366$Ym4.6243(a)text.news.virginmedia.com... > "Rod Pemberton" <do_not_have(a)havenone.cmm> wrote in message > news:hj3tk9$vbf$1(a)speranza.aioe.org... > > "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message > > news:hj28p7$na4$1(a)news.albasani.net... > >> > >> malloc is a function, and not a keyword. > > > > True... But, that's an entirely different topic: > > > > for(), while(), return(), switch(), sizeof() could all be implemented as > > functions. It might even be possible to do it an be compliant. > > Difficult I think. .... > How do you pass the block of code forming the main part > of for() and while(), which needs to be evaluated many times? Why would the code block, either loop conditional or loop body, need to be "passed"? (Passing code is for object-oriented languages.) FYI, one thing you didn't mention was that return() (and possibly sizeof() .... ?) can be used without () paren's, so there would still be some limitations (non-critical IMO) to implementing them as functions. Anyway, for() can be transformed into simpler loops such as while(). for(a;b;c) { d; } Becomes: a; while(b) { d; c; } if() and while() can fairly easily be converted to a assembly with branches and conditionals. They don't need to be kept as a functions, but could be with more work. Implementing them as functions might be useful to simplify parsing, or might be useful for generating assembly code in a specific manner. (I won't get into the reasons to do the latter.) To keep them as fuctions, it's likely their condition would be computed via a temporary, e.g., while(a<b) { c; } Becomes: /* pseudo assembly and C code */ /* one of a few possible methods... */ /* var's must be register based due to stack correction */ void while(int _while_condition, void* goto_l1, void* goto_l2) { /* "assembly" */ _stack_corrections; _if(_while_condition) _jump goto_l1; _else _jump goto_l2; } /* C code */ _tmp=a<b; label3: while(_tmp,label1,label2); /* while() as a function */ label1: c; _tmp=a<b; goto label3 label2: It's a bit convoluted, and unecessary under normal circumstances, but does have a few uses. > How do you > return from a function implementing return? Stack adjustment. You remove the called frame from the stack. That puts you back into the prior function's frame. When the return() function returns, it's to wherever the prior function would've returned. A similar thing is done in interpreters which have a called function to exit. Two return addresses are on the stack. One of them is because the exit function was called. That one must be popped. The other exits the interpreter. > Or evaluate sizeof() which must > be a compile-time value? You'll have to tell me why it must be a compile-time value, if a run-time value is identical in value... The code has no "understanding" of when or how a constant is generated. If the result is the same, it works ... (?) Is this a spec. requirement? I can't imagine that it is a requirement or C interpreters would never be compliant with the spec. They can never generate a compile-time value. That would be one big thorn in the side of C portability. > Or allow goto into and out of the statements? Same as is done now. The branch distance would just be larger... You were thinking that the loop conditional and loop body needed to be "passed". Hopefully, I've demonstrated that that isn't the case. > Or > access the local variables of the surrounding code? If needed somewhere, different prolog and epilog. I.e., don't create a new stack frame or remove the current frame immediately. This could be thought of as-if C had nested procedures... The nested procedure has access to the variables of the main procedure. Rod Pemberton
From: robertwessel2 on 19 Jan 2010 13:58
On Jan 19, 6:08 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote: > "bartc" <ba...(a)freeuk.com> wrote in message > > Or evaluate sizeof() which must > > be a compile-time value? > > You'll have to tell me why it must be a compile-time value, if a run-time > value is identical in value... The code has no "understanding" of when or > how a constant is generated. If the result is the same, it works ... (?) > Is this a spec. requirement? I can't imagine that it is a requirement or C > interpreters would never be compliant with the spec. They can never > generate a compile-time value. That would be one big thorn in the side of C > portability. Compile time constant expressions are allowed in a number of places. Some notable ones are array dimensions, the values in case values, and the values assigned to enumerators, which must be "integer constant expressions." A slight complication is that in C99 *may* be evaluated at runtime if it's referencing a VLA. Also automatic arrays may be defined as variable length (VLA) using a non-constant expression. But except in the case of VLAs, sizeof is defined to return a constant, which allows the value to use used at compile time. A couple of examples: int i; #if sizeof(i) < 4 ... #endif char c1[100]; char c2[sizeof(c1)]; |