[comp.lang.fortran] Changing constants

geiser@apollo.UUCP (01/23/87)

(Chuck McManis @ Sun Microsystems, Inc.) writes:

>Of course there was a time when you could right a Fortran program for
>TOPS-10 like so :
>
>	FOO(0.0,10)
>
>	SUBROUTINE FOO(A,B)
>	A = B * 3
>	RETURN
>	END
>And when executed the compiler generated constant for zero was a pointer
>to some known word with zero in it was changed. This affected all subsequent
>references to the constant 0.0 by your program or anyone elses on the
>system!
>
>-- 
>--Chuck McManis
>uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
>These opinions are my own and no one elses, but you knew that didn't you.

    Have you tried this program on any of your own equipment?  Both Sun2's and Sun3's
allow you to do this.  The code produced is slightly different for each, though.

    For example:

        PROGRAM MAIN
        CALL SUBR(1,2,3)
        CALL SUBR(1,2,3)
        END

        SUBROUTINE SUBR(I,J,K)
        WRITE(6,*) I
        I = 3
        RETURN
        END

    The results produced by this code are:

Sun3:
=====
  1
  3

Sun2:
=====
  1
  3  2  3

    In the Sun3 case, constants are pooled by procedure and therefore only the constant for
the main program gets changed.

    In the Sun2 case constants are pooled for the whole program.  When the IO routine gets
called the second time, it's told to print 1 value, 1 is now 3 and it prints the next two
constants (memory locations) as well.

    I would say this is a rather intriguing way to control output of arrays, etc.  You
no longer have to put in those tedious implied DO-lists.  Just change the constant 1 to
however many elements of the array you'd like to print before the IO statement and change it
back after you're done.  Neat, huh?  And just think of the job security benefit! :-)
(Sorry, I couldn't resist.)

                             Wayne Geiser
                             Apollo Computer, Inc.
                             {wanginst, yale, uw-beaver, brunix, utah-cs}!apollo!geiser

oster@lapis.berkeley.edu.UUCP (01/24/87)

My favorite "job security" hack in Fortran is done as follows:
1.) Take a routine that is called from only one or two places in the code,
compile it separately, at make a file of the pure machine bits that
result.
2.) Express that bit pattern as the result of a series of floating point
operations. Ideally, you'd like a matrix of floating point numbers that
when inverted has the same bit pattern as the code routine in <1.)>.
3.) use DATA //... to make that an array of initialized data in your
program.
4.) At some inconspicuous point in the running of the program, apply the
transform, so the array now holds the correct bit pattern for machine
code. (A really clever programmer will do the transform in widely
scattered pieces.)
5.) pass the array as an argument to a procedure. (Say the third argument
of FOO.)
6.) Declare the third argument of FOO as a procedural parameter. That way
step 5 will run it.

To anyone who comes after you, this will be completely opaque. Note:
Although many machines have non-writable code space, almost all machines
will execute out of data space. If your machine won't, a refinement of
this technique is to write a p-code interpreter, (where say, each byte
does a different operation) and pass your inverse of an initialized
floating point matrix to your p-code interpreter.

Anyone see the Apple ][ game based on the reference in my signature?
According to a review I read, there was a sequence of operations you could
do to make it crash back to Apple's ROM Basic. But, you couldn't REALLY
crash it, you were in an illusion of ROM Basic created by the program to
make you think you had gotten out.
--- David Phillip Oster		-- "We live in a Global Village."
Arpa: oster@lapis.berkeley.edu  --
Uucp: ucbvax!ucblapis!oster     -- "You are Number Six."
pro