page@ulowell.UUCP (Bob Page) (12/09/86)
rmariani@watmum.UUCP (Rico Mariani) wrote in article <723@watmum.UUCP>: some INCREDIBLY horrible C code. Rico, where the hell do you get such ugly code? Anyway, on with our regularly scheduled article: >main() >{ > int box[1], i; > > (box+i)[0] = > (box+i)[0] = > (box+i)[0] = > (box+i*i)[0] = 0; >} The Manx V3.30e (beta version) compiler and assembler like this code. Witness the difference between V3.20a and V3.30e (please excuse any little typos; I'm typing this in by hand): Old (V3.20a) code: New (V3.30e) code: ----------------- ----------------- move.l -8(a5),d3 move.l -8(a5),d1 asl.l #2,d3 move.l -8(a5),d0 jsr .mulu# lea -4(a5),a6 move.l -8(a5),d2 asl.l #2,d2 asl.l #2,d0 lea -4(a5),a1 lea -4(a5),a0 clr.l (a0,d0.l) move.l -8(a5),d1 move.l -8(a5),d2 asl.l #2,d1 asl.l #2,d2 lea -4(a5),a0 lea -4(a5),a1 clr.l (a1,d2.l) move.l -8(a5),d0 move.l -8(a5),d3 move.l d1,-(sp) move.l -8(a5),d1 jsr .mulu# asl.l #2,d0 asl.l #2,d3 move.l a6,-(sp) lea -4(a5),a6 lea -4(a5),a6 clr.l (a6,d0.l) clr.l (a6,d3.l) clr.l (a0,.l) clr.l (a1,d2.l) move.l (sp)+,a6 move.l (sp)+,d1 move.l -8(a5),d3 asl.l #2,d3 lea -4(a5),a6 clr.l (a6,d3.l) clr.l (a6,d3.l) The new Manx compiler (at least the beta version) is producing much tighter code these days. And in this case, better code too. We've seen some problems with the libraries (some types that should be 16-bit values are in the libraries as 32-bit values), but the compiler itself seems to be doing pretty well. ..Bob (beta testing the Manx compiler, if you hadn't guessed) -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
rmariani@watmum.UUCP (Rico Mariani) (12/10/86)
In article <836@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >rmariani@watmum.UUCP (Rico Mariani) wrote in article <723@watmum.UUCP>: >some INCREDIBLY horrible C code. Rico, where the hell do you get such >ugly code? Anyway, on with our regularly scheduled article: Where am I getting this code you ask? Well... I've just finished porting Maple to the Amiga (Maple is a language for performing symbolic computations) anyways, Maple is written not in C but in a language called Margay (written locally) which can be compiled into C. The examples of code that I gave were basically Margay output which I then simplified as much as possible (such as making all the subscripts 0). The result was the smallest peice of code I could find that still had the bug. >main() >{ > int box[1], i; > > (box+i)[0] = > (box+i)[0] = > (box+i)[0] = > (box+i*i)[0] = 0; >} Which doesn't look very much like the Margay output and doesn't look *anything* like the Margay source. Please don't try writing code like this at home, writing this code takes years of practice. Now a question: has anyone ever used the heapmem32.o module? sbrk() calls? I think there's a bug in that library somewhere... I'll try to come up with a minimal code fragment that illustrates this... Also there is a bug in the #line directive, sometimes the preprocessor "misses" the # and the C gripes about me not having declared the idenifier "line". I'll get a minimal fragment for that too... -Rico