Re: How does this make you feel?



Jason Ozolins wrote:
> prep@xxxxxxxxxxxxxxxx wrote:
> >>Jason Ozolins wrote:
>
> [listing system programmers, app programmers, end users]
>
> >>>This is listed in *increasing* order of importance - think of the
> >>>relative numbers in each group. NOTE WELL: the end user doesn't
> >>>care in the least about computer architecture aesthetics. They
> >>>either want a faster computer, a cheaper computer, or some
> >>>amazingly useful new feature.
> >
> > No it is in inverse order, because problems at lower levels flow up to
> > bite the end user EVEN IF HE DOES NOT KNOW OR CARE. Pentium FP
> > anyone...
>
> That's actually not a counterexample: The FDIV bug was nasty because there
> was no easy way to isolate its effects from app programmers and end users.
> The only ways to completely work around it would have been super-ugly, like
> dynamically translating FP code to insert checks/fixups around FDIVs, or
> disabling the FPU and interpreting each FP opcode in a trap handler.
>
> Consider the "F00F" bug that crashes old Pentiums. There is a workaround for
> it that can be done purely at the OS level. In fact, many of the errata
> listed by Intel for their processors are handled by the folks writing the OS,
> and you don't get to know about them. In those cases, a quite nasty bug for
> the OS implementors is of no concern to the end user.

This is all rather obvious, and indeed natural, as the hierarchy of
programming that comprises a functioning computer system that supports
applications suitable and usable to non-specialist users: i.e. word
processing apps and the like. However there may be some confusion of
nomenclature here as some people will conflate the use of words like
bug and feature since they are sometimes synonymous. "One man's bug is
another man's feature" type thing.

> So:
> Bugs that are visible all the way up to the end user: big impact.
> Bugs that can be handled by apps programmers: some impact
> Bugs that can be handled by system programmers without appreciable overhead:
> who cares?

Of course, it is difficult to see how the pentium FOOF or FDIV bugs
could be percieved by anyone as features, save in the pathalogical case
where their behavior is a side effect of some other cause. I recall
reading about an instance where someone modified the CPU of a PDP to
add some useful feature and unintentionally caused working code to
malfunction in some bizarre way. I don't recall how the issue was
resolved, but that is not important. The issue here from my
perspective is that, sure, it is necessary to be extremely careful when
modifying existing systems so as to retain existing functionality.
However, it does not seem reasonable to be too conservative in design
simply to avoid the risk that something _might_ break in the field if
regression testing cannot cover all the cases during a shakedown
period.

> This fits with what I was asserting:
> Features visible to end users (increased speed, new capabilities, better
> reliability): big impact
> Features that make life easier for apps programmers: some impact
> Features that only get noticed if you're an OS programmer: who cares?

We can restate your two sections to make your approach clearer:

Bugs or features visible to end users: big impact.
Bugs or features that make life easier for application programmers:
some impact.
Bugs or features that are only noticed by OS programmers: who cares?

> Just treat a bug as a "negative feature" and the relation holds.

That is an interesting identity, but it is not necessarily valid.
(True) features are capabilities that are usually designed into a
system. Actual bugs are generally side-effects of inadequate design or
implementation. They are not entities that are diametrically opposed
like "good" and "evil", much as many of us are conditioned or
predisposed to think that way. The intention behind a feature, such as
what I was proposing earlier, is to improve the quality of an arbitrary
system.

> Say you propose a new mechanism for handling page faults on some processor.
> Let's say with this new mechanism the average code path through the fault
> handler is reduced by 50%, but the fault handler execution time only drops by
> 1% because the big limiter is memory latency. This new feature might be
> appreciated by system programmers writing a new OS, because their fault
> handling code gets simpler, but will be pretty much invisible to the end
> user. A feature that is only appreciated by systems programmers is of
> limited commercial value.

You are correct with your example as it is written. However, the world
is not standing still. What happens when CPU clocking hits the wall,
and on-chip optimisation of instruction execution yields only linear
improvements in performance? Memory latencies are likely to improve
until they, too, hit a wall (speed of light signal propogation limits,
etc.) In this scenario, the ratio between instruction execution speed
and memory access frequencies is bound to settle into a different
stable state than the one that exists today. And even further out in
the left-field of speculation, we have optical gates, qbits, and
so-called quantum computing technologies on the horizon whose impact on
architecture is at present a matter of rank speculation.

> By contrast, take the Altivec SIMD extensions for the PowerPC. Introducing
> this feature makes *more work* for apps programmers - they have to write new
> code to take advantage of the new instructions - but assuming that Altivec
> doesn't slow down the rest of the processor, this is offset by the happiness
> of users who get better media player performance or quicker response from
> Photoshop, etc, and who pay money to get hold of that new feature (as well as
> software upgrades). That feature is of much greater commercial value than
> the better page fault handler feature.

Maybe. While I recognise the role to be played by commercial and
markeet valuation of technologies, I believe that should not be the
only consideration. There is the conception of a `social good' in our
society which is manifested in various ways. To the extent that
architecture dictates software design, there is a question as to what
architecture, or architecture features, lends itself to the creation of
the most useful tools, and hence contributes to the construction of the
most useful and functional applications. There are two basic
directions that this can go, and I happen to favour the one that is
more CISC than RISC.

The RISC direction looks to have been explored fairly thouroughly. As
to memory latencies, RISC seems to place the largest demand on the
memory bus in terms of feeding instructions to the CPU, and while a lot
of the busiest code will tend to fit in cache, there are still memory
latency issues with off-CPU access. At the extreme side of RISC, I
recall reading an article called "An introduction to array logic" (H.
Fleisher and L. I. Maissel, IBM J. Res., March, 1975 [v.20]) which
describes a system of logic programming that "can, in principle, be
changed at the same rate at which memory can be written". If this
method were adapted to CPU design, we would have a very RISC CPU that
was used essentially programmed by in-memory microcode. The recent and
now long-standing frequency differential between the CPU clocks and
memory bus speeds meant that it was not economically feasible to build
CPUs and write code generators for this kind of architecture.

I am approaching this problem from a different angle, and perhaps some
of this will help a couple of people who have stated that they do not
really understand what I propose. Instructions that can do more per
instruction cycle, which in this case means ranged memory operations,
in a parallel HW thread architecture, reduce cache memory footprints,
may exploit the memory bus more fully than existing designs, and add
features that may be exploited by compiler optimisers to improve code
efficiency.

And of course, as I have said, more flexible paging may (or should) be
a natual follow-on to complement a different kind of register that
would be needed to represent addressing modes that specify
quasi-arbitrary spans of memory.

> My point to Steve in my posting was that to sell anyone on a new ISA, you
> need to nail down enough specifics about the implementation to make some
> predictions about who (if anyone) will actually see a reason to use a
> processor based on that ISA. In doing so, the opinions of OS implementors
> and apps programmers are usually heavily outweighed by the end users, who
> want something like a smaller/faster/lighter gadget, or a faster word
> processor/games box/web browser, and couldn't care less whether the processor
> is elegantly powerful or a dog's breakfast that gets the job done. Some of
> them (not so much the open source crowd) would also like all the binary-only
> software that was installed on their last computer to work on their new
> computer too. :-/

You say that 'end users' don't care about the architecture so long as
it 'gets the job done' but as you know, to some degree the design of
the architecture dictates how applications will perform and how they
are written. However, this topic branches off into the psychology of
design and innovation, and I am not yet prepared to write at length on
the issue. It must suffice to say that at least as far as programmers
are concerned, the tools they use to construct applications contain a
great many implicit assumptions that are specified by the structure of
the systems they are using. I am not quite convinced that the shape of
existing systems meets all the present and future needs of programmers.
And it must be remembered that existing tool chains represent a body
of work that will be harder to change the longer that an existing ISA
persists in shaping them. So, what is considered a bug or a feature at
this level is a matter of conviction or allegiance to a particular
design philosophy.

Whether or not complex registers are the Right Thing To Do is almost
immaterial at this level of abstraction. Part of the intent of my
discussion of this issue at all is to gauge prevalent opinions on the
shape of existing CPU design, at least in the mid to low-end of the
market. I have an opinion about the kind of system that I would like
to write software for, and you are getting it. :) As for the high-end
of things in the world of supercomputers, I simply have no way to have
an informed opinion. Hopefully my demonstration of ignorance is not
too amusing to those who work on those systems.

I will attempt to make a more detailed case for my approach later on as
time permits.

> John Mashey has made the point that one of the few places a new ISA could get
> traction these days is in embedded devices. Even there, aesthetics aren't
> what matters, it's engineering: lower power implementations, reduced time to
> market, lower manufacturing cost are all ways to sell a new processor
> architecture. So Steve would still need to come up with a pragmatic
> justification for his new ISA.

With the potential for demonstrable and real gains, and conditional on
backwards compatibility, it is not unreasonable to expect that ISA
upgrades might also impact conventional systems. But the point is well
taken. Niche makets present the best entry point for experimental
designs in an industry largely dominated by traditional designs and
practises.


Regards,

Steve

.

Relevant Pages

  • Re: Rene is a hypocrite (OK, what else is new?)
    ... I dont know any avarage programmers. ... RosAsm doesnt detect it. ... But AoA is no longer very useful, unless HLA is involved. ... The right click feature is espesially nice in a monofile architecture. ...
    (alt.lang.asm)
  • Re: Whats the deal with C99?
    ... be in the language. ... languages by itself speaks volumes about what programmers want. ... There's no feature added to C99 that addresses even one thing that has ... There's no controversy about memory management? ...
    (comp.lang.c)
  • Re: [Lit.] Buffer overruns
    ... >> Such bugs can lead to security vulnerabilities. ... > The proper way to prevent this is to not hire totally stupid programmers. ... memory to some degree. ...
    (sci.crypt)
  • Re: Decouple SQL queries from class in OOP design
    ... > programmers (or business analysts, or software engineers, or project ... > Is this feature really qualify for an 80/20 rule of any sort? ... > programmers worrying about how to color-code text to each user's taste ... The new model of biz is to give the "customer" what they WANT. ...
    (comp.object)
  • Re: Has MS given up on us (again)?
    ... would just bite the bullet and merge the two language teams. ... Instead of C# leaping ahead with one particular new feature for one release, ... I find often C programmers hold these same feelings too. ... C was terse and powerful among languages back in the day and Basic ...
    (microsoft.public.dotnet.languages.vb)