From: cross@spitfire.i.gajendra.net
In article <107mf9l$u2si$1@dont-email.me>,
Thomas Koenig wrote:
>Dan Cross schrieb:
>> In article <107b1bu$252qo$1@dont-email.me>,
>
>>>Programming a RISC in assembler is not so hard, at least in my
>>>experience. Plus, people overestimated use of assembler even in
>>>the mid-1975s, and underestimated the use of compilers.
>>>[...]
>>
>> They certainly did! I'm not saying that they're right; I'm
>> saying that business needs must have, at least in part,
>> influenced the ISA design. That is, while mistaken, it was part
>> of the business decision process regardless.
>
>It's not clear to me what the distinction of technical vs. business
>is supposed to be in the context of ISA design. Could you explain?
I can attempt to, though I'm not sure if I can be successful.
The VAX was built to be a commercial product. As such, it was
designed to be successful in the market. But in order to be
successful in the market, it was important that the designers be
informed by the business landscape at both the time they were
designing it, and what they could project would be the lifetime
of the product. Those are considerations that extend beyond
the purely technical aspects of the design, and are both more
speculative and more abstract.
Consider how the business criteria might influence the technical
design, and how these might play off of one another: obviously,
DEC understood that the PDP-11 was growing ever more constrained
by its 16-bit address space, and that any successor would have
to have a larger address space. From a business perspective, it
made no sense to create a VAX with a 16-bit address space.
Similarly, they could have chosen (say) a 20, 24, or 28 bit
address space, or used segmented memory, or any number of other
such decisions, but the model that they did chose (basically a
flat 32-bit virtual address space: at least as far as the
hardware was concerned; I know VMS did things differently) was
ultimately the one that "won".
Of course, those are obvious examples. What I'm contending is
that the business<->technical relationship is probably deeper
and that business has more influence on technology than we
realize, up to and including the ISA design. I'm not saying
that the business folks are looking over the engineers'
shoulders telling them how the opcode space should be arranged,
but I am saying that they're probably going to engineering with
broad-strokes requirements based on market analysis and customer
demand. Indeed, we see examples of this now, with the addition
of vector instructions to most major ISAs. That's driven by the
market, not merely engineers saying to each other, "you know
what would be cool? AVX-512!"
And so with the VAX, I can imagine the work (which started in,
what, 1975?) being informed by a business landscape that saw an
increasing trend towards favoring high-level languages, but also
saw the continued development of large, bespoke, business
applications for another five or more years, and with customers
wanting to be able to write (say) complex formatting sequences
easily in assembler (the EDIT instruction!), in a way that was
compatible with COBOL (so make the COBOL compiler emit the EDIT
instruction!), while also trying to accommodate the scientific
market (POLYF/POLYG!) who would be writing primarily in FORTRAN
but jumping to assembler for the fuzz-busting speed boost (so
stabilize what amounts to an ABI very early on!), and so forth.
Of course, they messed some of it up; EDITPC was like the
punchline of a bad joke, and the ways that POLY was messed up
are well-known.
Anyway, I apologize for the length of the post, but that's the
sort of thing I mean.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
