HAMER@VCUVAX.BITNET (ROBERT M. HAMER) (01/12/90)
I promised to convey some more information on how SAS compiles and stores compiled code when I got some more. First, I have made the analogy that the data step compiler turns out something like p-code or object code. The code is probably closer to object than p-code, although it goes through a p-code-like stage. Remember with what the Institute calls "Multivendor Architecture" (I know I can't spell) much of the code is portable, but there is a layer that is machine specific. The compilation process goes through a part that takes the source code and turns it into a p-code-like form that is machine independent, and the layer of machine-specific code turns that into specific object code for the platform. The object code does not have external references resolved, and there are some other unresolved references, too. This is what is stored by the Stored Program Facility. Among the things that happen at compile time is the building of the PDV. An authoritative source has told me that in version 6, although the PDV is mostly built at compile time, it can be added to at execution time. What that probably means is that the first step in executing stored program code is resolving external references to SAS datasets and ensuring that the PDV has the things in it that it needs to, and if it does not, adding more variables to the PDV. I will probably write some test programs and communicate them to you. To change the subject, anyone out there have SAS code to find all possible permutations of a set? Suppose I have the characters 1 2 3 4 5. There are 5! (120) possible permutations or orders (5!) that they can take on (e.g., 3 5 2 1 4). I want to generate all of them. Anyone have SAS code to do this?
ADPDKHTS@UIAMVS.BITNET (Deb Hawley 319-335-6321) (01/12/90)
> > The object code does not have external references resolved, and > there are some other unresolved references, too. This is what > is stored by the Stored Program Facility. > I apologize to the list if this is too technical of a question, but I can't help but think others might be interested, too. If SAS can handle unresolved references as you suggest, why did they stop with just the DATA step? There's no reason why references couldn't be resolved at run time to a library containing the SAS procs? (instead of copying in the entire thing and storing it in object code, as someone mentioned that was the reason SAS didn't include PROCS). That's the way I understand our PL/I libraries to work. Can you explain more? Deb Hawley Systems Programmer University of Iowa
HAMER@VCUVAX.BITNET (ROBERT M. HAMER) (01/12/90)
Deb Hawley 319-335-6321 <ADPDKHTS@UIAMVS.BITNET> writes: > I apologize to the list if this is too technical of a question, > but I can't help but think others might be interested, too. > > If SAS can handle unresolved references as you suggest, why > did they stop with just the DATA step? There's no reason why > references couldn't be resolved at run time to a library > containing the SAS procs? (instead of copying in the entire > thing and storing it in object code, as someone mentioned that > was the reason SAS didn't include PROCS). That's the way I > understand our PL/I libraries to work. Can you explain more? Deb: The PROCs are basically already compiled subroutines. They are written in C (I'm going to stick to version 6 but things hold pretty much the same conceptually for 5) and are called by the SAS supervisor. (Except for a couple of wierd procs procs like NLIN I think that actually have compilable statements.) The various options and statements one uses with a PROC like the PROC, VARIABLE, BY, etc statement really just set parameters which the already compiled proc. SAS probably could have a run-time library designed in like PL/I etc, but if they did, it would have to be huge. They probably chose not to. Some PROCS are a half meg or more just by themselves. If you do it with a run-time library you have a huge library; if you include the compiled code in your program you have a huge load module.
ADPDKHTS@UIAMVS.BITNET (Deb Hawley 319-335-6321) (01/12/90)
> > Those of us who grew up in IBM land tend to forget that everything is not the > way it is in CMS & MVS land. Even in Unix, the dynamic linking to a routine > is done entirely differently than is a directly linked call. This has been > one of the problems with Formats. On the IBM they were "subroutines" which > were dynamically called - they could not be implemented that way on other > platforms. > > In most modern operating systems which support virtual memory, the paging > mechanism is usually more efficient than the general disk access, thus better > performance is actually achived without dynamic invokation of library > routines. > > -phil > Thanks, this is the answer I was looking for, and it makes perfect sense. Since the only thing I've ever known is IBM CMS and MVS, it's easy to see where I needed the information!!! Deb