Editing IBM Future Systems project (section)

===HLS===
Evans also asked [[John McPherson (computer engineer)|John McPherson]] at IBM's [[Armonk, New York|Armonk]] headquarters to chair another group to consider how IBM would offer these new designs across their many divisions. A group of twelve participants spread across three divisions produced the "Higher Level System Report", or HLS, which was delivered on 25 February 1970. A key component of HLS was the idea that programming was more expensive than hardware. If a system could greatly reduce the cost of development, then that system could be sold for more money, as the overall cost of operation would still be lower than the competition.<ref name=hlsrep>{{cite tech report |url=http://www.jfsowa.com/computer/afs/HLS_1970.pdf |title=Higher Level System (HLS) |date=25 February 1970 |first=John |last=McPherson}}</ref>

The basic concept of the System/360 series was that a single [[instruction set architecture]] (ISA) would be defined that offered every possible instruction the [[assembly language]] programmer might desire. Whereas previous systems might be dedicated to scientific programming or currency calculations and had instructions for that sort of data, the 360 offered instructions for both of these and practically every other task. Individual machines were then designed that targeted particular workloads and ran those instructions directly in hardware and implemented the others in [[microcode]]. This meant any machine in the 360 family could run programs from any other, just faster or slower depending on the task. This proved enormously successful, as a customer could buy a low-end machine and always upgrade to a faster one in the future, knowing all their applications would continue to run.

Although the 360's instruction set was large, those instructions were still low-level, representing single operations that the [[central processing unit]] (CPU) would perform, like "add two numbers" or "compare this number to zero". [[Programming language]]s and their links to the operating system allowed users to type in programs using high-level concepts like "open file" or "add these arrays". The [[compiler]]s would convert these higher-level abstractions into a series of [[machine code]] instructions.

For HLS, the instructions would instead represent those higher-level tasks directly. That is, there would be instructions in the machine code for "open file". If a program called this instruction, there was no need to convert this into lower-level code, the machine would do this internally in microcode or even a direct hardware implementation.<ref name=hlsrep/> This worked hand-in-hand with the single-level store; to implement HLS, every bit of data in the system was paired with a ''descriptor'', a record that contained the type of the data, its location in memory, and its precision and size. As descriptors could point to arrays and record structures as well, this allowed the machine language to process these as atomic objects.<ref name=hlsrep/>

By representing these much higher-level objects directly in the system, user programs would be much smaller and simpler. For instance, to add two arrays of numbers held in files in traditional languages, one would generally open the two files, read one item from each, add them, and then store the value to a third file. In the HLS approach, one would simply open the files and call add. The underlying operating system would map these into memory, create descriptors showing them both to be arrays and then the add instruction would see they were arrays and add all the values together. Assigning that value into a newly created array would have the effect of writing it back to storage. A program that might take a page or so of code was now reduced to a few lines. Moreover, as this was the natural language of the machine, the [[command shell]] was itself programmable in the same way, there would be no need to "write a program" for a simple task like this, it could be entered as a command.<ref name=hlsrep/>

The report concluded:

{{quote|The user and IBM should both gain substantially from the easier coding and debugging of concise programs. We expect to sharply reduce the cost of programming and the size of complex programs, as both program quality and programmer productivity are enhanced.<ref name=hlsrep/>}}