Author |
Message |
Neil Ricke #1 / 41
|
--- Pseudo Registers ---
Quote:
>What are they? Is this an assembler term? How does one use them?
A pseudo register is a memory location that can be placed in dynamically allocated memory, yet there is a way of addressing it in multiple invocations of a procedure. The main use is that it allows a procedure to be reentrant and refreshable, yet it can maintain state across multiple calls to the procedure. The pseudo-register facility is used by PL/I for controlled external variables. It is accessible in Assembler. Most assembler programmers don't use pseudo-registers. But they can very useful in some circumstance. To use them, the main program should do an initial GETMAIN for the amount of space required by pseudo-registers. It can find how long with a CXD. Normally, the main program would also zero this area. Then it would place its address in a place where all routines can find it - perhaps in register 12, with all subroutines agreeing to preserve register 12 throughout. A program that requires a pseudo register use a DXD to define it, and a Q type constant to record the offset of the constant from the beginning of the allocated block. If the total pseudo-register area is less than 4096 bytes, then a trick that can be used is: PSREG DXD A ... L 3,0(12,0) ORG *-2 DC QL2(PSREG) This generates a load instruction to load the contents of the pseudo register into Reg 3.
|
Sun, 12 Aug 2001 03:00:00 GMT |
|
|
ChatNoir #2 / 41
|
--- Pseudo Registers ---
What are they? Is this an assembler term? How does one use them?
|
Mon, 13 Aug 2001 03:00:00 GMT |
|
|
s.. #3 / 41
|
--- Pseudo Registers ---
Neil Rickert did a good job describing pseudo-registers, but he missed a few items. First, in Assembler, pseudo registers are called "external dummy registers" Second, there are two pseudo-operations (CXD and DXD), not one, to define pseudo-registers. The CXD pseudo-operation defines a 1 word word aligned aligned data area that contains the length of all of the pseudo registers. Ultimately, this data area is filled in by the binder, relocating loader, or linkage editor program. The program uses this data to allocate the pseudo-register data area. Third, as Neil indicated, pseudo-registers are external symbols. If one program calls a pseudo-register A, then all programs use that name. Fourth, it is possible to define a pseudo-register to the reference name used for a DSECT. Z DSECT . . PGM CSECT . . L 3,=Q(Z) A 3,pseudo-reg-pointer USING Z,3 As Neil indicated, pseudo-register usage in Assembler programs is rare. Assembler H and the High Level Assembler removed some debilitating restrictions about their use that discouraged many people from using them in the early days. The concept is also unpopular in programming theory, since pseudo-registers define global data areas, and this practice is discouraged in programming theory.
Quote: >What are they? Is this an assembler term? How does one use them?
-- 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.
|
Mon, 13 Aug 2001 03:00:00 GMT |
|
|
Neil Ricke #4 / 41
|
--- Pseudo Registers ---
Quote:
>Neil Rickert did a good job describing pseudo-registers, but he missed a >few items.
Thank you for filling in the gaps. Quote: >As Neil indicated, pseudo-register usage in Assembler programs is rare. >Assembler H and the High Level Assembler removed some debilitating >restrictions about their use that discouraged many people from using >them in the early days. The concept is also unpopular in programming >theory, since pseudo-registers define global data areas, and this >practice is discouraged in programming theory.
Experienced programmers know better than to take such programming theory too seriously. Let me now give a different perspective. Global data areas are often useful. In the MVS or OS/390, the CVT is an example. A macro defines the CVT dsect. All modules use that definition, and reference it via a standard pointer address. Using this global communication table makes it possible for separately written modules to communicate with one another. If you wanted to design a system which used a table such as the CVT, you would put somebody in charge of the CVT design. Anyone who required a particular entry would submit a request to the person in charge. What pseudo-registers do, in effect, is automate this process. You submit a request for an entry in the global table with a DXD (or an external dummy sect referenced in a Q constant). The linkage editor builds the global table from all of the requests, and backfills the references (the Q-constants). The main reason that assembler programmers don't much use pseudo-registers, is that they are all control freaks (why else program in assembler, if you don't want to control the result). And a control freak doesn't like offloading such important decisions to the link editor. Well, okay, that last paragraph overstates things. The point is, that a centrally managed global table does the same thing, and allows better control over what you are doing.
|
Mon, 13 Aug 2001 03:00:00 GMT |
|
|
Tony Vitoni #5 / 41
|
--- Pseudo Registers ---
Quote: Neil Rickert wrote...
>>As Neil indicated, pseudo-register usage in Assembler programs is >>rare. Assembler H and the High Level Assembler removed some >>debilitating restrictions about their use that discouraged many people >>from using them in the early days. The concept is also unpopular in >>programming theory, since pseudo-registers define global data areas, >>and this practice is discouraged in programming theory. >Experienced programmers know better than to take such programming >theory too seriously.
I've been a programmer for a while, and I wasn't troubled by global data for the longest time. In the past couple of years, though, I've been learning some object-based and -oriented stuff on these toy computers, and my mind is changing. In particular, I *am* troubled by global data now, and I do my best to avoid it. I've either seen the light, or been fished in.
|
Mon, 13 Aug 2001 03:00:00 GMT |
|
|
ASTCO Ltd #6 / 41
|
--- Pseudo Registers ---
The main downside on pseudo registers (I thought they were called "external dummy sections" to the assembler) from our perspective is that they only work for single-load-module programs. We have numerous multi-load-module programs and have had to implement global areas using a different method. Judy Anderson Product Development Advanced Software Technologies Company, Ltd. Quote:
>>Neil Rickert did a good job describing pseudo-registers, but he missed a >>few items. >Thank you for filling in the gaps. >>As Neil indicated, pseudo-register usage in Assembler programs is rare. >>Assembler H and the High Level Assembler removed some debilitating >>restrictions about their use that discouraged many people from using >>them in the early days. The concept is also unpopular in programming >>theory, since pseudo-registers define global data areas, and this >>practice is discouraged in programming theory. >Experienced programmers know better than to take such programming >theory too seriously. >Let me now give a different perspective. >Global data areas are often useful. In the MVS or OS/390, the CVT is >an example. A macro defines the CVT dsect. All modules use that >definition, and reference it via a standard pointer address. Using >this global communication table makes it possible for separately >written modules to communicate with one another. >If you wanted to design a system which used a table such as the CVT, >you would put somebody in charge of the CVT design. Anyone who >required a particular entry would submit a request to the person in >charge. >What pseudo-registers do, in effect, is automate this process. You >submit a request for an entry in the global table with a DXD (or an >external dummy sect referenced in a Q constant). The linkage editor >builds the global table from all of the requests, and backfills the >references (the Q-constants). >The main reason that assembler programmers don't much use >pseudo-registers, is that they are all control freaks (why else >program in assembler, if you don't want to control the result). And >a control freak doesn't like offloading such important decisions to >the link editor. >Well, okay, that last paragraph overstates things. The point is, >that a centrally managed global table does the same thing, and allows >better control over what you are doing.
|
Mon, 13 Aug 2001 03:00:00 GMT |
|
|
Tony Vitoni #7 / 41
|
--- Pseudo Registers ---
Quote:
>People who claim that "global" data is always bad are as bad as people >who claim that "gotos" are always bad...there are often some good >reasons for using either.
Sure. I don't think I've seen anyone claim either of those things on this thread. Quote: >Some global data that really is global might be: > - environment information, e.g. the current value of the system >clock, the processor model, os-version, jes-ver, jobname, etc... - >shared memory, object fanatics will bite my head off for this one but, >if it is shared (and synch'ed) among all processes, why do we need to >wrap that in a layer of overhead so that all processes can access it >more slowly.... - certain communication vectors, stdin/stdout >(sysin/sysout, sysipt/syslst) - program to program communication, for >example a cics shared getmain area holding tables for all tasks to >read...
Some data seems meant to be shared, yes. I just think that, very often, global data is used where local data would help to avoid maintenance headaches. This is the real reason for the overhead -- which in most cases really isn't that much. Quote: >this list is hardly exaustive....and as long as I've thrown out this >flamebait, PROPERLY used GOTOs are just fine....
I agree. Quote: >I can't help it if most programmers are unable to know how to use them >PROPERLY....
Most? I don't know about that.
|
Wed, 15 Aug 2001 03:00:00 GMT |
|
|
cory hamasa #8 / 41
|
--- Pseudo Registers ---
Quote:
> Neil Rickert wrote...
> >Experienced programmers know better than to take such programming > >theory too seriously. > I've been a programmer for a while, and I wasn't troubled by global data > for the longest time. In the past couple of years, though, I've been > learning some object-based and -oriented stuff on these toy computers, > and my mind is changing. In particular, I *am* troubled by global data > now, and I do my best to avoid it. > I've either seen the light, or been fished in.
Keep a balance. Consider the relative stability of MVS which was built on global data and shared control blocks, to Windows NT, which is New Technology on Toy computers. And how can a location request a cumulative psuedo register length? Why was that message even issued. In 30 years in 3 different PL/I shops, I've never met anyone who understood that message or used it. cory hamasaki 305 Days, 7,337 Hours until it doesn't matter.
|
Fri, 17 Aug 2001 03:00:00 GMT |
|
|
Neil Ricke #9 / 41
|
--- Pseudo Registers ---
Quote:
>And how can a location request a cumulative psuedo register length? Why >was that message even issued. In 30 years in 3 different PL/I shops, >I've never met anyone who understood that message or used it.
I'm not sure what you are asking here. You request a cumulative pseudo-register length with CXD. The CXD generates a fullword, containing the combined pseudo-register length. This is possible, because the link editor fills in the details after combining all of the object modules it is linking. And yes, it does work and I have used it (although not very often).
|
Fri, 17 Aug 2001 03:00:00 GMT |
|
|
Tony Vitoni #10 / 41
|
--- Pseudo Registers ---
Quote: cory hamasaki wrote...
>> Neil Rickert wrote...
>>> Experienced programmers know better than to take such programming >>> theory too seriously. >> I've been a programmer for a while, and I wasn't troubled by global >> data for the longest time. In the past couple of years, though, I've >> been learning some object-based and -oriented stuff on these toy >> computers, and my mind is changing. In particular, I *am* troubled >> by global data now, and I do my best to avoid it. >> I've either seen the light, or been fished in. > Keep a balance. Consider the relative stability of MVS which was > built on global data and shared control blocks, to Windows NT, which > is New Technology on Toy computers.
There's a logical fallacy here: MVS was built on global data and is relatively stable, so it's relatively stable BECAUSE it was built on global data. "Post hoc ergo propter hoc", I think they call it. Anyway, I think that MVS is stable largely because it's been around for eons. Consider four service packs for NT 4 (soon going to five or six, I've heard) versus...how many{*filter*}tapes for MVS? Of course, there will be varying opinions on this, so: let the flames begin!
|
Fri, 17 Aug 2001 03:00:00 GMT |
|
|
phinias_t_phooba #11 / 41
|
--- Pseudo Registers ---
Quote:
> Consider four service packs for NT 4 (soon going to five or six, > I've heard) versus...how many{*filter*}tapes for MVS?
Subtle, but elegant point, destined for the Bill Gates Hall of Shame. Imagine trying to roll out yet *another* version of your already shakey system in late 1999? What a freakin' bone head. Any marketing or tech clown worth his salt could have told them that was a bad, bad, very bad idea. Ya, MVS is stable, but I don't like it because you have to layer it over with something like TSO, and you *still* don't get {*filter*} pictures on the monitor. I keep looking for a place to point 'n shoot but all I get is ugly, ugly menus or a command line that reminds me of being lost as a little kid. I never saw such huge, humungus, ugly, complicated command lines in my life. You have to be a sucker for punishment to do TSO. And if you mater it you *still* have no {*filter*}s. To me, that is not computing. -- - phinias t. phoobar (distant cousin of phinias t. bluster)
|
Fri, 17 Aug 2001 03:00:00 GMT |
|
|
s.. #12 / 41
|
--- Pseudo Registers ---
Say what you will about TSO command lines, but -- - There isn't a / or - in sight. - There are no cryptic one letter"switches". I grant the longer form keywords can be depressingly cryptic, but at least there is a little more substance. - Since, for the most part, a common service routine performs command line parsing, rather than every program doing a RYO command line parsing, the overall syntax is sort of consistent, and the error messages are completely consistent. Sometimes even helpful. - Though terminal operators tend to ignore this, command line errors can often be resolved through reentry of misunderstood input. How many toy or baby machines do this, rather than quit the command and require the entire command line to be reentered?
[deleted] Quote: >Ya, MVS is stable, but I don't like it because you have to layer it over with >something like TSO, and you *still* don't get {*filter*} pictures on the monitor. I >keep looking for a place to point 'n shoot but all I get is ugly, ugly menus or >a command line that reminds me of being lost as a little kid. I never saw such >huge, humungus, ugly, complicated command lines in my life. You have to be a >sucker for punishment to do TSO. And if you mater it you *still* have no >{*filter*}s. To me, that is not computing. >-- >- phinias t. phoobar (distant cousin of phinias t. bluster)
-- 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.
|
Fri, 17 Aug 2001 03:00:00 GMT |
|
|
Page 1 of 3
|
[ 41 post ] |
|
Go to page:
[1]
[2] [3] |
|