> >> That is not the reason. The reason is to get the > >> function/macro calls out of the > >> inner loop. > > > >Sorry, I can't see any loops there: > > > >SSize_t > >PerlIOStdio_read(PerlIO *f, void *vbuf, Size_t count) > >{ > > dSYS; > > FILE *s = PerlIOSelf(f,PerlIOStdio)->stdio; > > SSize_t got = 0; > > if (count == 1) > > { > > STDCHAR *buf = (STDCHAR *) vbuf; > > /* Perl is expecting PerlIO_getc() to fill the buffer > > * Linux's stdio does not do that for fread() > > */ > > int ch = PerlSIO_fgetc(s); > > if (ch != EOF) > > { > > *buf = ch; > > got = 1; > > } > > } > > else > > got = PerlSIO_fread(vbuf,1,count,s); > > return got; > >} > > But s is used in both branches of the if - so factoring it out saves code > size. ... but "buf" is never used except inside "if" condition, so it'll be faster to use it only when it is used. > > Sorry this is my style, it isn't completely pointless - having "loads" > at the top of the function tends help instruction schedulers put them > in the "right place". GCC at least used to fail to put "loads" like > that in the delay slot of the jump that implements the if() - it did > not spot that there was a "common" instruction in the two basic blocks. Nick, I really appreciate your perl/Tk work and am sure about high quality of your code. > >> Patches welcome. > > > >Okay. > >Here is a tiny-optimization patch. Although patch is obvious, I checked for perl to pass tests after applying it. > > > >--- d:\WORK\PerlCompile\perl@11148-orig\perlio.c Sat Jun 30 22:41:57 2001 > >+++ d:\WORK\PerlCompile\perl@11148\perlio.c Fri Jul 6 17:07:24 2001 > >@@ -2278,14 +2278,13 @@ > > SSize_t got = 0; > > if (count == 1) > > { > >- STDCHAR *buf = (STDCHAR *) vbuf; > > /* Perl is expecting PerlIO_getc() to fill the buffer > > * Linux's stdio does not do that for fread() > > */ > > int ch = PerlSIO_fgetc(s); > > if (ch != EOF) > > { > >- *buf = ch; > >+ *((STDCHAR *)vbuf) = ch; > > got = 1; > > } > > } > > Does that actually change the generated code at all? > IIRC there is at least one compiler which is used for perl which > does not like lvalue casts. I seem to remember doing the inverse of your > patch to fix that. mmm... I suggested not that much patches, so I have a feeling that I remember them all. One patch - to rule them all, one to forget, :) joke, forget this. Being serious, I have a feeling that all compilers must be able to do lvalue casts. If your experience says otherwise (I beleive your experience much wider that mine), then I'll do nothing except I'll agree with your point. Really warmest wishes, <!ENTITY Vadim REALLIFE "Vadim V.Konovalov, St.Petersburg, Russia"> &Vadim;Thread Previous | Thread Next