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