站久了腰疼是什么原因

This article is about the HP programming language. For the concept of a programming language for systems programming, see systems programming language.

Systems Programming Language
Paradigms	procedural, imperative, structured
Family	ALGOL
First appeared	1972 (1972)
Influenced by
ALGOL 60, ESPOL
Influenced
ZSPL, Micro-SPL, Action!

百度 凤凰网WEMONEY讯3月25日，红岭创投董事长周世平在红岭创投官网社区发布《2018年，红岭创投的自我革命》一文，就公司近期发展和战略转型等问题进行说明。

Systems Programming Language, often shortened to SPL but sometimes known as SPL/3000, was a procedurally-oriented programming language written by Hewlett-Packard for the HP 3000 minicomputer line and first introduced in 1972. SPL was used to write the HP 3000's primary operating system, Multi-Programming Executive (MPE). Similar languages on other platforms were generically referred to as system programming languages, confusing matters.

Originally known as Alpha Systems Programming Language, named for the development project that produced the 3000-series, SPL was designed to take advantage of the Alpha's stack-based processor design. It is patterned on ESPOL, a similar ALGOL-derived language used by the Burroughs B5000 mainframe systems, which also influenced a number of 1960s languages like PL360 and JOVIAL.

Through the mid-1970s, the success of the HP systems produced a number of SPL offshoots. Examples include ZSPL for the Zilog Z80 processor, and Micro-SPL for the Xerox Alto. The later inspired Action! for Atari 8-bit computers, which was fairly successful. The latter more closely followed Pascal syntax, losing some of SPL's idiosyncrasies.

SPL was widely used during the lifetime of the original 16-bit version of the HP 3000 platform. In the 1980s, the HP 3000 and MPE were reimplemented in an emulator running on the PA-RISC-based HP 9000 platforms. HP promoted Pascal as the favored system language on PA-RISC and did not provide an SPL compiler. This caused code maintenance concerns, and 3rd party SPL compilers were introduced to fill this need.

History

Hewlett-Packard introduced their first minicomputers, the HP 2100 series, in 1967. The machines had originally been designed by an external team working for Union Carbide and intended mainly for industrial embedded control uses, not the wider data processing market. HP saw this as a natural fit with their existing instrumentation business and initially pitched it to those users. In spite of this, HP found that the machine's price/performance ratio was making them increasingly successful in the business market.

During this period, the concept of time sharing was becoming popular, especially as core memory costs fell and systems began to ship with more memory. In 1968, HP introduced a bundled system using two 2100-series machine running HP Time-Shared BASIC, which provided a complete operating system as well as the BASIC programming language. These two-machine systems, collectively known as HP 2000s, were an immediate success. HP BASIC was highly influential for many years, and its syntax can be seen in a number microcomputer BASICs, including Palo Alto TinyBASIC, Integer BASIC, North Star BASIC, Atari BASIC, and others.

Designers at HP began to wonder "If we can produce a time-sharing system this good using a junky computer like the 2116, think what we could accomplish if we designed our own computer." To this end, in 1968 the company began putting together a larger team to design a new mid-sized architecture. New team members included those who had worked on Burroughs and IBM mainframe systems, and the resulting concepts bore a strong resemblance to the highly successful Burroughs B5000 system. The B5000 used a stack machine processor that made multiprogramming simpler to implement, and HP selected this same architecture for the new concept.

Two implementations were considered, a 32-bit mainframe-scale machine known as Omega, and a 16-bit design known as Alpha. Almost all effort was on the Omega, but in June 1970, Omega was canceled. This led to an extensive redesign of Alpha to differentiate it from the 2100s, and it eventually emerged with plans for an even more aggressive operating system design. Omega had intended to run in batch mode and use a smaller computer, the "front end", to process interactions with the user. This was the same operating concept as the 2000 series. However, yet-another-2000 would not be enough for Alpha, and the decision was made to have a single operating for batch, interactive and even real-time operation.

To make this work, it needed an advanced computer bus design with extensive direct memory access (DMA) and required an advanced operating system (OS) to provide quick responses to user actions. The B5000 was also unique, for its time, in that its operating system and core utilities were all programmed in a high-level language, ESPOL. ESPOL was a derivative of the ALGOL language tuned to work on the B5000's, a concept that was highly influential in the 1960s and led to new languages like JOVIAL, PL/360, and BCPL. The HP team decided they would also use an ALGOL-derived language for their operating systems work. HP's similar language was initially known as the Alpha Systems Programming Language.

Alpha took several years to develop before emerging in 1972 as the HP 3000. The machine was on the market for only a few months before it was clear it simply wasn't working right, and HP was forced to recall all 3000's already sold. It was reintroduced in late 1973 with most of its problems having been fixed. A major upgrade to the entire system, the CX machine, and MPE-C to run on it, reformed its image and the 3000 went on to be another major success during the second half of the 1970s.

This success made SPL almost as widespread as the 2000 series' BASIC, and like that language, SPL resulted in a number of versions for other platforms. Notable among them was Micro-SPL, a version written for the Xerox Alto workstation. This machine had originally used BCPL as its primary language, but dissatisfaction with its performance led Henry Baker to design a non-recursive language that he implemented with Clinton Parker in 1979. Clinton would then further modify Micro-SPL to produce Action! for Atari 8-bit computers in 1983.

HP reimplemented the HP 3000 system on the PA-RISC chipset, running a new version of the operating system known as MPE/iX. MPE/iX had two modes, in "native mode" it ran applications that had been recompiled for the PA-RISC using newer Pascal compilers, while under "compatible mode" it could run all existing software via emulation. HP did not supply a native mode compiler for MPE/iX so it was not an easy process to move existing software to the new platform. To fill the need, Allegro Consultants wrote an SPL-compatible language named "SPLash!" that could compile to original HP 3000 code to run within the emulator, or to native mode. This offered a porting pathway for existing SPL software.

Language

Basic syntax

SPL generally follows ALGOL 60 syntax conventions, and will be familiar to anyone with experience in ALGOL or its descendants, like Pascal and Modula-2. Like those languages, program statements can span multiple physical lines and end with a semicolon. Comments are denoted with the COMMENT keyword, or by surrounding the comment text in << and >>.

Statements are grouped into blocks using BEGIN and END, although, as in Pascal, the END of a program must be followed by a period. The program as a whole is surrounded by BEGIN and END., similar to Pascal, but lacking a PROGRAM keyword or similar statement at the top. The reason for this is that SPL allows any block of code to be used as a program on its own, or compiled into another program to act as a library. The creation of code as a program or subprogram was not part of the language itself, handled instead by placing the $CONTROL SUBPROGRAM compiler directive at the top of the file.

The language provided the INTRINSIC keyword to provide an easy method for declaring external procedures, thus avoiding the need for the programmer to declare the procedure parameter types and order. All user-accessible system service declarations (such as file system, process handling, communications, and the like) were available through this mechanism, and users could also add their own procedure declarations to the system's INTRINSIC list. This is similar to, but more refined and narrower scope than the C-language #include mechanism.

In contrast to Pascal, where PROCEDURE and FUNCTION were separate concepts, SPL uses a more C-like approach where any PROCEDURE can be prefixed with a type to turn it into a function. In keeping with the syntax of other ALGOL-like languages, the types of the parameters were listed after the name, not part of it. For instance:

INTEGER PROCEDURE FACT(N); VALUE N; INTEGER N;

Declares a function FACT that takes a value N that is an integer. The VALUE indicates that this variable is "pass-by-value" and therefore changes to it inside the procedure will not be seen by the caller. The procedure sets its return value by an assignment statement to its name:

FACT := expression;

Although frowned upon, ALGOL and Pascal allowed code to be labeled using a leading name ending with a colon, which could then be used for the target of loops and GO TO statements. One minor difference is that SPL required the label names to be declared in the variable section using the LABEL keyword.

SPL added to this concept with the ENTRY statement which allowed these labels to be further defined as "entry points" that could be accessed from the command line. Labels named in the entry statement(s) were exposed to the operating system and could be called from the RUN command. For instance, one could write a program containing string functions to convert to uppercase or lowercase, and then provide ENTRY points for these two. This could be called from the command line as RUN $STRINGS,TOUPPER.

Data types

Where SPL differs most noticeably from ALGOL is that its data types are very machine specific, based on the 3000's 16-bit big-endian word format.

The INTEGER type is a 16-bit signed type, with 15 bits of value and the least significant bit as the sign. DOUBLE is a 32-bit integer, not a floating-point type. REAL is a 32-bit floating-point value with 22 bits for the mantissa and 9 for the exponent, while LONG is a 64-bit floating-point value with 54 bits of mantissa and 9 bits exponent.

BYTE is used for character processing, consisting of a 16-bit machine word holding a single 8-bit character in the least-significant bits. Arrays of type BYTE pack two 8-bit characters per 16-bit machine word. LOGICAL is an unsigned 16-bit integer type that, when used in a conditional expression, returns true if the least-significant bit is 1 and false otherwise. Unsigned integer arithmetic can be performed on LOGICAL data and any overflow is ignored. There is no equivalent of a PACKED modifier as found in Pascal, so LOGICAL is somewhat wasteful of memory when used only to store a single binary digit, although SPL offers bit string manipulation as an alternative.

Like C, data is weakly typed, memory locations and variable storage are intermixed concepts, and one can access values directly through their locations. For instance, the code:

INTEGER A,B,C
LOGICAL D=A+2

defines three 16-bit integer variables, A, B and C, and then a LOGICAL, also a 16-bit value. The =, like Pascal, means "is equivalent to", not "gets the value of", which uses := in Algol-like languages. So the second line states "declare a variable D that is in the same memory location as A+2", which in this case is also the location of the variable C. This allows the same value to be read as an integer via C or a logical through D.

This syntax may seem odd to modern readers where memory is generally a black box, but it has a number of important uses in systems programming where particular memory locations hold values from the underlying hardware. In particular, it allows one to define a variable that points to the front of a table of values, and then declare additional variables that point to individual values within the table. If the table location changes, only a single value has to change, the initial address, and all of the individual variables will automatically follow in their proper relative offsets.

Pointers were declared by adding the POINTER modifier to any variable declaration, and the memory location of a variable dereferenced with the @. Thus INTEGER POINTER P:=@A declares a pointer whose value contains the address of the variable A, not the value of A. @ can be used on either side of the assignment; @P:=A puts the value of A into P, likely resulting in a dangling pointer, @P:=@A makes P point to A, while P:=A puts the value of A into the location currently pointed to by P.

In a similar fashion, SPL includes C-like array support in which the index variable is a number-of-words offset from the memory location set for the initial variable. Unlike C, SPL only provided one-dimensional arrays, and used parentheses as opposed to brackets. Variables could also be declared GLOBAL, in which case no local memory was set aside for them and the storage was assumed to be declared in another library. This mirrors the extern keyword in C.

Literals can be specified with various suffixes, and those without a suffix are assumed to be INTEGER. For instance, 1234 would be interpreted as an INTEGER, while 1234D was a DOUBLE. E denoted a REAL and L a LONG. String constants were delimited by double-quotes, and double-quotes within a line were escaped with a second double-quote.

Variable declarations could use constants to define an initial value, as in INTEGER A:=10. Note the use of the assign-to rather than is-a. Additionally, SPL had a EQUATE keyword that allowed a string of text to be defined as a variable, and then replaced any instances of that variable in the code with the literal string during compiles. This is similar to the const keyword in C.

Memory segmentation

The classic HP 3000 organized physical memory into 1, 2, 4, 8, or 16 banks of 64K (65536) 16-bit words (128K bytes). Code (shared, non-modifiable) and data were separate from each other and stored in variable-length segments of up to 32K words each. Within a process, data addresses such as pointers were 16-bit offsets from a base register (known as DB), or relative offsets from a pointer register (Q or S) that resulted in a valid address within the process's data area (called the stack). While primarily 16-bit word-oriented, the system supported addressing of individual bytes in an array by using the word address where the byte was stored shifted left 1 bit then adding 0 to access the upper byte, or 1 for the lower byte. Thus byte addresses were separate and distinct from word addresses and the interpretation of an address was purely contextual. This proved to be quite troublesome and was the source of numerous bugs in both system and user code. Care had to be taken to treat byte addresses as 16-bit unsigned (that is, type LOGICAL) when using them in, for example, length computations, because otherwise a byte address of 2^16 or more would be treated as a 2s-complement signed value resulting in erroneous calculation of lengths or offsets.

An individual process had access to up to 254 code segments of up to 32K words each. The code segments were divided into two domains: the first 191 were "system" segments shared by all processes, and the remaining 63 were "user" segments shared by all running the same program. Control transfer specified either a routine number within the current segment, or an external segment number and a routine number within it. A small table at the end of the segment provided the entry point address for the routine.

A process's code acted on data in the stack, a single private segment also up to 32K words in size. Unlike stacks in other architectures, the HP 3000 stack was used for process globals, state preservation, procedure locals (supporting nested calls and re-entrancy), and numeric computation/evaluation. The operating system provided facilities for access to additional memory-based (non-stack) data segments, but these were not natively addressed by the instruction set and so the program was responsible for moving data from and to such "extra data segments" as necessary.

SPL included a variety of support systems to allow programs to be easily segmented and then make that segmentation relatively invisible in the code. The primary mechanism was to use the $CONTROL SEGMENT=asegmentname compiler directive which defined which segment the following code should be placed in. The default was MAINLINESEG, but the programmer could add any number of additional named segments to organize the code into blocks.

Other features

SPL included a "bit-extraction" feature that allowed simplified bit fiddling. Any bit, or string of bits, in a word could be accessed using the .(x:y) syntax, where x and y were the start and end bit positions from 0 to 15. (Significantly, x and y must be constants known at compile time.) Thus A.(8:15) returned the lower byte of the word storing A. This format could be used to split and merge bits as needed. Additionally, additional operations were provided for shifts and rotates, and could be applied to any variable with the &, for instance A:=A & LSR(3).

Example

This simple program, from the 1984 version of the reference manual, shows most of the features of the SPL language.

The program as a whole is delimited between the BEGIN and END.. It begins with the definition of a series of global variables, A, B and C, defines a single procedure and then calls it twenty times. Note that the procedure does not have a BEGIN and END of its own because it contains only one line of actual code, X:=X*(Y+Z); the INTEGER X,Y,Z is not considered part of the code itself, it is indicating the type of the three parameters being passed in on the line above and is considered part of that line.

 BEGIN
     INTEGER A:=0, B, C:=1;
     PROCEDURE N(X,Y,Z);
         INTEGER X,Y,Z;
         X:=X*(Y+Z);
     FOR B:=1 UNTIL 20 DO
         N(A,B,C);
 END.

References

Bibliography

• Edler, Christopher (November 1995). "The Strongest Castle: The Rise, Fall and Rise of the HP 3000". The Analytical Engine. 3 (1). ISSN 1071-6351. Archived from the original on 3 February 2002.
• Green, Bob (2004). HP3000 Evolution. Robelle.
• Leibson, Steve (2017). "HP: The Accidentally, On-Purpose Computer Company". HP9825.COM.
• Systems Programming Language reference manual (PDF). Hewlett-Packard. February 1984.