Article View: comp.sys.intel
Article #308Re: PLM vs. C for 80286/80386 (long)
From: Vernon Schryver
Date: Wed, 12 Jul 1989 06:21
Date: Wed, 12 Jul 1989 06:21
125 lines
6132 bytes
6132 bytes
There has been some discussion about PLM386 vs. C in this newsgroup. Some
have said that PLM386 does a reasonable job, and so does C. Tonight, I've
had occassion to look at the output of PLM386 with optimize(3). It is
ugly. If iC386 is as bad, then one would be wise to talk to Motorola, AMD,
MIPS, or the SPARK clones. It appears that in the 8 years since I stared
closely at large gobs of PL/M86 output, INTEL has not improved the
"optimizer". They still do not know the relevance of "peep hole." Because
I wish to share my disgust, included below is a small function, and
PLM386's best effort. The function is not coded wonderfully, but that is
no excuse for the slop the compiler emits.
This is a small chunk of a disgustingly large file, from the days when it
had to be compiled "large" and multiple files meant extra segment register
usage and lots more code, and it had to fit in 2716's
The lower case text in the code output are my comments.
$code
1192 1 hex$arith: procedure reentrant;
1193 2 declare ptr pointer;
1194 2 call read$char;
1195 2 call get$addr(@ptr,selector(0)); /* takes ptr&selector */
1196 2 call put$string(@(' = ',0)); /* takes a ptr */
1197 2 call put$ptr(ptr,0); /* takes ptr */
1198 2 if selector(ptr)<>data_seg /* a selector */
1199 2 then do; /* '&&' would be nice */
1200 3 if not ck$ptr(ptr,1) /* takes ptr & word */
1201 3 then do;
1202 4 call put$word(flatten(ptr),0);
1203 4 call put$string(@(' base=',0));
1204 4 call put$word(flatten(build$ptr(selector(ptr),0)),0);
1205 4 call put$string(@(' limit=',0));
1206 4 call put$word(get$segment$limit(selector(ptr)),0);
1207 4 end;
1208 3 end;
1209 2 end hex$arith;
$nocode
; STATEMENT # 1192
HEXARITH PROC NEAR
000028DC 55 PUSH EBP
000028DD 8BEC MOV EBP,ESP
000028DF 51 PUSH ECX ? dense but slow since it
000028E0 51 PUSH ECX ? makes extra memory traffic
? why not ENTER 8 ?
; STATEMENT # 1194
000028E1 E8F6DFFFFF CALL READCHAR
; STATEMENT # 1195
000028E6 8D45FA LEA EAX,[EBP].PTR
000028E9 16 PUSH SS ; 1
000028EA 50 PUSH EAX ; 2
000028EB B800000000 MOV EAX,0H ? what's wrong with XOR EAX,EAX
? 2 bytes instead of 5
000028F0 50 PUSH EAX ; 3 ? what's wrong with PUSH 0?
000028F1 E856E8FFFF CALL GETADDR
; STATEMENT # 1196
000028F6 B8C5020000 MOV EAX,OFFSET(@@LONG$CONSTANT$02C5H)
000028FB 0E PUSH CS ; 1
000028FC 50 PUSH EAX ; 2
000028FD 0E PUSH CS ? what's wrong with long calls?
000028FE E815E2FFFF CALL PUTSTRING
; STATEMENT # 1197
00002903 FF75FE PUSH [EBP].PTR+4H; 1
00002906 FF75FA PUSH [EBP].PTR; 2
00002909 6A00 PUSH 0H !see, it knows about PUSH 0
0000290B E8B4E1FFFF CALL PUTPTR
; STATEMENT # 1198
00002910 668B55FE MOV DX,[EBP].PTR+4H
00002914 8B45FA MOV EAX,[EBP].PTR ?why? Completely dead!?
00002917 662E3B1500000000CMP DX,CS:DATA_SEG ?why not CMP [EBP].PTR..
0000291F 7467 JZ @284
; STATEMENT # 1200
00002921 FF75FE PUSH [EBP].PTR+4H; 1
00002924 FF75FA PUSH [EBP].PTR; 2
00002927 6A01 PUSH 1H
00002929 E852E6FFFF CALL CKPTR
0000292E A801 TEST AL,1H
00002930 7556 JNZ @284
; STATEMENT # 1202
00002932 FF75FE PUSH [EBP].PTR+4H; 1
00002935 FF75FA PUSH [EBP].PTR; 2
00002938 0E PUSH CS ?why not a far call
00002939 E800000000 CALL FLATTEN
0000293E 50 PUSH EAX ; 1
0000293F 6A00 PUSH 0H
00002941 E85EE1FFFF CALL PUTWORD
; STATEMENT # 1203
00002946 B8C9020000 MOV EAX,OFFSET(@@LONG$CONSTANT$02C9H)
0000294B 0E PUSH CS ; 1
0000294C 50 PUSH EAX ; 2
0000294D 0E PUSH CS
0000294E E8C5E1FFFF CALL PUTSTRING
; STATEMENT # 1204
00002953 668B45FE MOV AX,[EBP].PTR+4H ?why not PUSH [EBP]....
00002957 B900000000 MOV ECX,0H ?why not PUSH 0 ?
0000295C 50 PUSH EAX ; 1
0000295D 51 PUSH ECX ; 2
0000295E 0E PUSH CS
0000295F E800000000 CALL FLATTEN
00002964 50 PUSH EAX ; 1
00002965 6A00 PUSH 0H
00002967 E838E1FFFF CALL PUTWORD
; STATEMENT # 1205
0000296C B8D0020000 MOV EAX,OFFSET(@@LONG$CONSTANT$02D0H)
00002971 0E PUSH CS ; 1
00002972 50 PUSH EAX ; 2
00002973 0E PUSH CS
00002974 E89FE1FFFF CALL PUTSTRING
; STATEMENT # 1206
00002979 668B45FE MOV AX,[EBP].PTR+4H
0000297D 0F03C0 LSL EAX,EAX
00002980 50 PUSH EAX ; 1
00002981 6A00 PUSH 0H
00002983 E81CE1FFFF CALL PUTWORD
; STATEMENT # 1208
; STATEMENT # 1209
@284:
00002988 C9 LEAVE
00002989 C3 RET
HEXARITH ENDP
Vernon Schryver
vjs@calcite.uucp
Technical Details
Message-ID:
<52@calcite.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!sdsu!decwrl!sgi!calcite!vjsReferences:
<598@philtis.UUCP> <14381@bfmny0.UUCP> <1765@auspex.auspex.com> <239@guardian.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!sdsu!decwrl!sgi!calcite!vjs From: vjs@calcite.UUCP (Vernon Schryver) Newsgroups: comp.sys.intel Subject: Re: PLM vs. C for 80286/80386 (long) Summary: ugh! Message-ID: <52@calcite.UUCP> Date: 12 Jul 89 06:21:36 GMT References: <598@philtis.UUCP> <14381@bfmny0.UUCP> <1765@auspex.auspex.com> <239@guardian.UUCP> Organization: Rhyolite Software, Mountain View, CA Lines: 125