My professor made this claim... 
Author Message
 My professor made this claim...

My professor said that it would only take 40 lines of 370 assembly to
write a relocatable loader.  I said I didn't think so and I'd have to
see it to believe it.  He claimed he saw students in the past who had
done it in 40.

Please note: While this relocatable loader is for an assignment, the
argument about being able to code it in 40 lines is not.  This is about
lines of written code, not size or speed or efficiency.

The loader must provide relocation (but not linking), and support all
address lengths.  The input file is assumed to be 100% valid and no
error checking is needed (a poor real-world assumption).

This was the smallest I could squeeze the thing down to (and it works).
I've numbered the lines of code; comments obviously don't count towards
the total.

*
* A relocatable loader.
* Assumes input file is valid, relocatable only (no linking).
* NO ERROR CHECKING.
*
MAIN      CSECT                         01
* Setup.
          STM 14,12,12(13)              02
          BALR 12,0                     03
          USING *,12                    04
          ST 13,SAVEREG+4               05
          LA 13,SAVEREG                 06
* Open file, read and process cards.
          LA 10,LDAREA                  07
          OPEN FILEIN                   08
READING   GET FILEIN,CARDBUF            09
          CLC CARDBUF+1(3),=C'TXT'      10
          BNE NOTTXT                    11
*  Process TXT cards.
*   Get address.
          XR 4,4                        12
          ICM 4,B'0111',CARDBUF+5       13
          AR 4,10                       14
*   Get length.
          LH 5,CARDBUF+10               15
*   Copy data.
          BCTR 5,0                      16
          EX 5,MVCTXT                   17
          B READING                     18
MVCTXT    MVC 0(0,4),CARDBUF+16         19
*
NOTTXT    CLC CARDBUF+1(3),=C'RLD'      20
          BNE NOTRLD                    21
*  Process RLD cards.
*   Get length of RLD specs.
          LH 5,CARDBUF+10               22
*   Point to 1st RLD spec and last for loop.
          LA 4,CARDBUF+16+4             23
          LA 9,CARDBUF+16(5)            24
*    Get address to adjust.
NEXTRLD   XR 6,6                        25
          ICM 6,B'0111',1(4)            26
          AR 6,10                       27
*    Get length to adjust (0000LL00 of byte).
          IC 7,0(4)                     28
          N 7,=F'12'                    29
          SRL 7,2                       30
          IC 7,LEN2MSK(7)               31
*    Get value to adjust (into 5).
          EX 7,ICMADR                   32
*    Adjust by adding or subtracting relocation factor.
          TM 0(4),2                     33
          BZ ADDREL                     34
          SR 5,10                       35
          B STADJ                       36
ADDREL    AR 5,10                       37
*    Store adjusted value (from 5).
STADJ     EX 7,STCMADR                  38
*   Point to next RLD spec (either 4 or 8 bytes fwd).
          LA 8,8                        39
          TM 0(4),1                     40
          BZ RLDFWD8                    41
          LA 8,4                        42
*   Jump to next type and address spec.
RLDFWD8   BXLE 4,8,NEXTRLD              43
          B READING                     44
LEN2MSK   DC B'0001',B'0011',B'0111',B'1111'
ICMADR    ICM 5,0,0(6)                  46
STCMADR   STCM 5,0,0(6)                 47
*
NOTRLD    CLC CARDBUF+1(3),=C'END'      48
          BNE READING                   49
*  Process END card.
*   Get address if not blank.
          XR 15,15                      50
          CLC CARDBUF+5(3),=X'404040'   51
          BE BLANKADR                   52
          ICM 15,B'0111',CARDBUF+5      53
BLANKADR  AR 15,10                      54
*   Transfer.
          BALR 14,15                    55
* Close file, clean up, and leave.
EOFHDLR   CLOSE FILEIN                  56
          L 13,SAVEREG+4                57
          LM 14,12,12(13)               58
          BR 14                         59
* Data
CARDBUF   DS CL80                       60
FILEIN    DCB MACRF=G,DDNAME='DEMOLDR',RECFM=F,LRECL=80,
               BLKSIZE=80,EODAD=EOFHDLR 62
SAVEREG   DS 18F                        63
LDAREA    DS 256D                       64
          END MAIN                      65

65 lines!  I feel I can justify the need for each and every line of code
in this loader, and don't see how you could squeeze this into 40.  It
would take about 40 just do do the TXT and END cards.

As I'm writing this, I suddenly get the idea to make all the DCs and DSs
into literals, but that would save only 4 lines.  I can't think of any
other way to shave lines (DC X'already assembled code' doesn't count).

Am I missing something big that would save 25 lines?  Like an
instruction or SVC that can do the entire process in 1 step?



Fri, 20 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:
> My professor said that it would only take 40 lines of 370 assembly to
> write a relocatable loader.  I said I didn't think so and I'd have to
> see it to believe it.  He claimed he saw students in the past who had
> done it in 40.

By this definition, one could claim one line in pre- and early HLASM compilers, *zero* lines in current HLASM compilers, with no assembler macro invocations.  I leave it, however, to your imagination on how to solve this.

Mark L. Gaubatz
With opinions that are mine alone...



Fri, 20 Apr 2001 03:00:00 GMT  
 My professor made this claim...
One possible optimization (just for the segment I left) --

         IC    7,0(,4)
         N     7,=A(B'0001100')
         EX    0,ICM(7)
         .
STADJ    EX    0,STCM(7)
         .
         DC    0H'0'
ICM      EQU   *-4
         DC    2H'0'
         ICM   5,B'0111',0(6)
         ICM   5,B'1111',0(6)
STCM     EQU   *-8
         STCM  5,B'0111',0(6)
         STCM  5,B'1111',0(6)

After the N, reg 7 is a power of 4.  Use it for the indexed
ICM and STCM.  It is arranged so that a 2-byte relocatable area
will ABEND.


[snip]

Quote:
>*    Get length to adjust (0000LL00 of byte).
>          IC 7,0(4)                     28
>          N 7,=F'12'                    29
>          SRL 7,2                       30
>          IC 7,LEN2MSK(7)               31
>*    Get value to adjust (into 5).
>          EX 7,ICMADR                   32
[snip]
>STADJ     STCM 7,ICMADR                   38
[snip]
>LEN2MSK   DC B'0001',B'0011',B'0111',B'1111'
>ICMADR    ICM 5,0,0(6)                  46
>STCMADR   STCM 5,0,0(6)                 47

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Sun, 22 Apr 2001 03:00:00 GMT  
 My professor made this claim...

You can decode 'TXT', 'RLD', 'END', and 'ESD' by taking the second
character and anding it with X'06'.  You can use this as an offset into
a two byte relative jump table.  

Implementation details left to the reader.  Reference the newsgroup.

-- glen



Sun, 22 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:

> Wow, that is truly twisted.
> I wonder why they didn't just put in a code like 01 for TXT and 02 for RLD
> though.  It seems like it would not only save space in the file but make
> the loader code simpler as well.  And it would be more, well, logical.
> Also, the use of blanks (40h) is a nuisance.  Why couldn't they have put 00

> in the gaps so we could read the addresses as words (which is supposedly
> faster)?  And 404040h in the END card is supposed to be "blank" but what
> would happen if your program really was that big and that really was the
> starting address?

First of all, I think that the technique outlined by extracting the second
character is pretty good. There are other CARDS that need to be considered
however; like the REP and SYM.

Second, notice I capitalized CARDS. That's because that's how all of this
started its life. The X'02' punch in column 1 was the 21-11-0-7-8-9 combo.
I *THINK* - Gotta go back to the original green card for this! (Actually,
the punches were present in subsequent GCs, but I forget where it stopped)

Wow, NULL must be a youngster...



Sun, 22 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:

> Since macros (open, close, etc) appear to count as a single line, you could
> use the IBM provided SAVE/RETURN macros and trim 7 lines from standard entry
> and exit code.  That should get you to 58 lines...

> In a few places, I think you could adjust the way you are loading values (XR,
> ICM, otherOp) to ditch the leading XR...depends on the value, maybe not.

Yeah, I thought about having one dedicated register with its high byte zeroed
once to be used in all the ICM/STCMs.  Unfortunately, this would save only 1 line
as there is only 1 other place it could be used.

Quote:
> Constructs like:
> >           LA 4,CARDBUF+16+4             23
> >           LA 9,CARDBUF+16(5)            24
> could be turned into:
>             LM Ra,Rb,=2A(CARDBUFF_OFF_16,CARDBUFF_OFF_20)

How's that?  CARDBUFF_OFF_20 unfortunately does not include the vital register 5
offset (length of RLD specs) added onto it since this is only available at that
point in execution.  It would take another A or LA instruction to put it there.

The instructor explained that data related statements don't count towards the
criteria, so we can whack about 6 more lines off.  I'm getting pretty close but
still don't think it's reachable.



Mon, 23 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:

> You can decode 'TXT', 'RLD', 'END', and 'ESD' by taking the second
> character and anding it with X'06'.  You can use this as an offset into
> a two byte relative jump table.

> Implementation details left to the reader.  Reference the newsgroup.

> -- glen

Wow, that is truly twisted.
I wonder why they didn't just put in a code like 01 for TXT and 02 for RLD
though.  It seems like it would not only save space in the file but make
the loader code simpler as well.  And it would be more, well, logical.
Also, the use of blanks (40h) is a nuisance.  Why couldn't they have put 00

in the gaps so we could read the addresses as words (which is supposedly
faster)?  And 404040h in the END card is supposed to be "blank" but what
would happen if your program really was that big and that really was the
starting address?



Mon, 23 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:


> > Wow, that is truly twisted.
> > I wonder why they didn't just put in a code like 01 for TXT and 02 for RLD
> > though.  It seems like it would not only save space in the file but make
> > the loader code simpler as well.  And it would be more, well, logical.

True, but this way the card types were "readable" by the human eye. Besides
REP cards were frequently made manually with the IBM29 or IBM129
card punches (remember those anybody?) and that justified plain text
wherever possible. Also see my next comment on card physical strength.

Quote:

> > Also, the use of blanks (40h) is a nuisance.  Why couldn't they have put 00
> > in the gaps so we could read the addresses as words (which is supposedly
> > faster)?

No speed difference in those days, and using blanks instead of lots of
12-0-1-8-9 punches made the cards stronger. Card crashes were not at
all uncommon, and caused much delays and trouble, especially with
binary card decks.

Quote:
>  And 404040h in the END card is supposed to be "blank" but what
> > would happen if your program really was that big and that really was the
> > starting address?

That is a really good question. Luckily this never became a problem with the
machine sizes in use at the time. Load addresses in the ranges above
100000h (or x'100000' as we usually wrote) hardly ever occurred.

Quote:

> First of all, I think that the technique outlined by extracting the second
> character is pretty good. There are other CARDS that need to be considered
> however; like the REP and SYM.

> Second, notice I capitalized CARDS. That's because that's how all of this
> started its life. The X'02' punch in column 1 was the 21-11-0-7-8-9 combo.

No, it was a plain 12-2-9

Quote:

> I *THINK* - Gotta go back to the original green card for this! (Actually,
> the punches were present in subsequent GCs, but I forget where it stopped)

Oh, they are still present in my Yellow card (S/370) from November 1976
and in the EBCDIC chart in one of the appendixes in my PoP - also on
S/370 XA - from January 1987.

Quote:

> Wow, NULL must be a youngster...

Quite likely since "his professor made this claim". After all I realize I worked
on these matters back in the 60s and 70s - that is 30 years ago!
Was NULL even born by then?

regards Sven



Mon, 23 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:
>Second, notice I capitalized CARDS. That's because that's how all of this
>started its life. The X'02' punch in column 1 was the 21-11-0-7-8-9 combo.
>I *THINK* - Gotta go back to the original green card for this! (Actually,

12-11-0-9-8-7 was X'FF', once called a "zigamorph"

Judy Anderson
Product Development
Advanced Software Technologies Company, Ltd.



Mon, 23 Apr 2001 03:00:00 GMT  
 My professor made this claim...


Quote:

>>Second, notice I capitalized CARDS. That's because that's how all of this
>>started its life. The X'02' punch in column 1 was the 21-11-0-7-8-9 combo.
>>I *THINK* - Gotta go back to the original green card for this! (Actually,

>12-11-0-9-8-7 was X'FF', once called a "zigamorph"

And, according to my copy of the "System 370 Operator's Reference
Manual", "Code Translation Table", x'02' is/was the 12-2-9 combo.


Mon, 23 Apr 2001 03:00:00 GMT  
 My professor made this claim...

Quote:

>...
>faster)?  And 404040h in the END card is supposed to be "blank" but what
>would happen if your program really was that big and that really was the
>starting address?

You've rediscovered the original "Green Slime" problem! It turns out that
two things are needed to get into trouble: address 404040h and ESDid 4040h.

It would have been nice if compilers promised never to generate this ESDid,
in which case the start address could be unrestricted, and would be presumed
given only when the ESDid at offset 14 was not 4040h.  Unfortunately that's
not the case, and I did once generate an object file (with assembler H) that
exposed the problem.  A small change in the source, and the entry point used
by the loader changed from offset 404042h to (effectively) offset zero, and
the program "failed".

Michel.



Mon, 23 Apr 2001 03:00:00 GMT  
 My professor made this claim...
Does anyone still have the "3 card loader" that was used to IPL a text
deck from the card reader?  I remember dis-assembling it some time
around 1968.  As I recall, the first card only had an initial PSW and a
couple CCWs, so the whole program was pretty small.  I can't remember if
it did relocation or not, but possibly this is what the professor is
thinking of.  

Bill Fenlason



Tue, 24 Apr 2001 03:00:00 GMT  
 My professor made this claim...
Is there anything that says it needs to be run as a subprogram called by
another routine?  If not, for example if you were always invoked by the
LINK or ATTACH macros or as a stand-alone job step, you could do away with
saving the registers, chaining/unchaining the save areas, etc.  Just get
your base register from BALR/BASR or LR and go for it.  The R13 you will
be using is that provided by the system.  When you're finished, just issue
SVC 3 to return (assumes MVS and/or OS/390 operating system).

--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Wed, 25 Apr 2001 03:00:00 GMT  
 My professor made this claim...
I've resisted replying until now...

Quote:

>My professor said that it would only take 40 lines of 370 assembly to
>write a relocatable loader. <snip>
>This was the smallest I could squeeze the thing down to <snip>
>* A relocatable loader.
>* Assumes input file is valid, relocatable only (no linking).

Also assumes the relocated program is < 256 doublewords.
Also ignores possibility of linker/binder directives in obj (via PUNCH).
Also ignores possibility of newer object file formats.
Also ... (so many issues, so little time)

Quote:
>* NO ERROR CHECKING. !!!!YESS!!!!
>*
>MAIN      CSECT                         01
<snip>
>65 lines!  I feel I can justify the need for each and every line of code
>in this loader, and don't see how you could squeeze this into 40.  It
>would take about 40 just do do the TXT and END cards.

You could shorten this code somewhat by slightly more elaborate programming
techniques, but the main question I would ask is "why?". So far your
professor has been "underwhelming" in the absolutism of his remarks to your
class.

I don't think anyone who regularly hangs around this NG would dare claim
that a code fragment was either computationally perfect (it wasn't) or that
a relatively complex problem (like a program loader) could or should be
written in some (small) number of instructions.

I don't see any educational value in his remarks. They would seem to me to
be more intimidating than instructive, given that most of the class
presumably are there precisely because they ARE beginners.

Ask him to enumerate the issues with the 40 line "solution" and see if they
hold up to inspection.

Chris.



Wed, 25 Apr 2001 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. My professor said.....

2. Professor of Computer Science

3. Another Berkeley Math Professor gets some real bad luck

4. Professor of Computer Science

5. Professor Mark Overmars' - new software release

6. Full professor position

7. Automatic Professor Machine

8. Position as Professor in Computer Science

9. JOB OPENING: Visiting Professor - US Air Force Academy

10. Senior Professors Teaching Intro CS

11. Open associate professor position at ESDlab

12. Red-faced professor gets bitten in search for portability

 

 
Powered by phpBB® Forum Software