🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.intel
Article #308

Re: PLM vs. C for 80286/80386 (long)

#308
From: Vernon Schryver
Date: Wed, 12 Jul 1989 06:21
125 lines
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!vjs
References: <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