Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
On Mon, Oct 29, 2012 at 11:58:23PM +, Charles Forsyth wrote: > > But suppose the standard does not evidently aim to be understood, in the > generally understood meaning of "understood", > or there are more words in the standard than will ever appear in the > programmer's own programs? Do you mean as if standards were designed or "improved" by committees? Please: stop spreading FUD! (Were are my drops? I have tachycardia again!) -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
On Mon, Oct 29, 2012 at 04:26:52PM -0700, Bakul Shah wrote: > > Best way to save developer time is to program in a HLL and not > worry about bit fiddling. C is not a HLL. The HLL will have to have a compiler. If the compiler is, finally, machine instructions, how does one guarantee that it does exactly what intended on different architectures. If the next level language, near machine but high level is used---it's C---you are relying on what you wanted to escape from... The only mean to be sure is to have a HLL that allows only HL instructions, like macroscopic, due to its complexity, escapes from the uncertainty of quantics effects. This is to say, the language will not allow you to do everything. The practical solution is to have a language that is near the machine, sufficiently abstracted from the machines that assembly is scarcely needed, with some small set of primitives, a small manual, a clear (once again: small) set of what is guaranteed and caveats about what is not, and let the programmer decide without the compiler "guessing" or improving---and a way of writting sources so that a programmer can optimize his code on this level (this is litterate programming). C was very near a perfect practical solution; C89 was not bad; C99 has improved some things but added too many things on the border (where there is already uncertainty about what has to be done because "it depends"). -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] Still a few more days to submit papers for iwp9 - and more than a week to submit WIP/Demos/Posters :)
Still time to contribute ... Sincerely Eric
Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
> Best way to save developer time is to program in a HLL and not > worry about bit fiddling. C is not a HLL. C was created as a language to do bit fiddling in - a tool for writing assembly language a bit more productively than doing it by hand. The original Unix C compiler was a tool for writing PDP11 assembly language. Later when the prospect of Unix on other architectures began to emerge, the 7th edition Unix "portable C compiler" was a family of tools for writing assembly language on different machines. C was designed by and used by systems programmers who were intimately familiar with their machine's instruction set, and the code generation was so simple and straightforward that to such programmers it would be obvious what instructions would correspond to a given bit of C. The low-level directness of C made it easy to write efficient code, so there was no need for the compiler itself to try to do clever "optimisations". Such a language was and still is just what is needed for writing device drivers and the lowest layers of OS kernels where things like memory layout and instruction ordering are important. It's not such a good match for writing the more abstract upper layers of an OS, and even less so for applications programming. I think it's unfortunate that C ended up being so widely (mis)used for applications programming, and by applications programmers who have never learned assembly language, causing pressure for compilers to be obfuscated with semantics-perverting "optimisations" and, in an attempt to compensate for this, the language to be defaced with "features" like volatile and __attribute__ and whatnot. I think inferno got it about right: write the kernel in C, and the applications in a high level language (limbo).
Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
On Tuesday 30 of October 2012 10:26:52 Richard Miller wrote: > > Best way to save developer time is to program in a HLL and not > > worry about bit fiddling. C is not a HLL. > > C was created as a language to do bit fiddling in - a tool for writing > assembly language a bit more productively than doing it by hand. (..) slightly branching off: true that. however, people still manage medium-to-high level with a bit of macros and advanced stuff. the other day i browsed http://9hal.ath.cx/usr/cinap_lenrek/cifsd.tgz -- looks high-level enough for me. putty uses home-brew coroutines in portable C, as per http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html -- dexen deVries [[[↓][→]]] How often I found where I should be going only by setting out for somewhere else. -- R. Buckminster Fuller
Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
On Mon Oct 29 23:17:25 EDT 2012, cthom.li...@gmail.com wrote: > On 29 October 2012 23:06, Bakul Shah wrote: > > > > > gcc etc. are used to deliver a lot of code that is used in > > real word. And without a standard there would've been lot > > less interoperability and far more bugs. > > > Most interoperability delivered by gcc comes from the fact that gcc is > widespread, not that the standard is effective. If it was we wouldn't need > to port gcc to everything. even clang got forced into bug-for-bug compatability mode. - erik
Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
> > > gcc etc. are used to deliver a lot of code that is used in > > > real word. And without a standard there would've been lot > > > less interoperability and far more bugs. This remains true. It is possible and not that difficult to write code that can be successfully and correctly compiled by multiple compilers (like, oh, i dunno, maybe, GNU awk :-). > > Most interoperability delivered by gcc comes from the fact that gcc is > > widespread, not that the standard is effective. If it was we wouldn't need > > to port gcc to everything. > > even clang got forced into bug-for-bug compatability mode. Also the Intel compiler, ICC. Like many things, standards seem to obey a bell curve. The problem is that we're on the descending side on so many of them... (Dare I say it? "POSIX". Freel free to run screaming in horror. :-) Having lived through the Unix wars of the late 80s and early 90s, I think that overall standards are a good thing. It just seems that more recently the comittees keep adding stuff in order to justify their continued existence, instead of solving real problems. Arnold
[9fans] resize
i found a little bug today with one-pixel tracking images. (yahoo.co.jp, for
instance.)
i don't think this program is in the distribution.
; diffy -c resize.c
/n/dump/2012/1030/sys/src/cmd/resize.c:17,24 - resize.c:17,24
bpp = src->depth/8;
bpl = src->width*sizeof(int);
- qp.x = (ssize.x<<12)/dsize.x;
- qp.y = (ssize.y<<12)/dsize.y;
+ qp.x = (ssize.x<<12)/(dsize.x==0? 1: dsize.x);
+ qp.y = (ssize.y<<12)/(dsize.y==0? 1: dsize.y);
_sp.y = sr.min.y<<12;
for(dp.y=0; dp.y<=dsize.y; dp.y++){
sp.y = _sp.y>>12;
