Re: How does this make you feel?

[blame slow news propogation]

Jan Vorbrüggen wrote:
> >>Rather, I'd think that smart programmers showed they could use RISC
> >>primitives to implement, say, a memcpy just as efficiently as microcode
> >>could, except perhaps for some of the cache effects (see below) and, of
> >>course, at the expense of quite complicated code to handle all possible
> >>alignments etc.
> > But this is what computers are for: makeing the job easier for the
> > user. If it is possible to offload work from the programmer in such a
> > common case, why not?
>
> The work is offloaded from the programmer in any case - this type of code
> is written "once" and then either called from a library or inlined by the
> compiler (possibly taking advantage of the compiler's knowledge of lengths
> and alignments in the process).

This is likely valid for VHDL (or Verilog) as well. Perhaps the
library macros need updating for new CPU products, but that's also true
for system libraries. So, what's better? memcpy() as a few tens of
in-line assembler instructions, or as a bunch of gates sitting on the
chip?

Let's assume we're talking about normal CPUs and not special products
for, say, embedded applications where die size, unit cost, and power
consumption might affect the economics related to the inclusion of
on-chip bit movers. Certainly a toaster has no need for a CPU with
luxuries of this kind, but a cell-phone might.

> >>>- It is no accident that it takes 2 pages to describe MVCL.
> >>Indeed. And it increases the likelihood some implementation gets some
> >>corner case wrong.
> > Laugh. Well there are always going to be people who don't fully read
> > the documentation as they should!
>
> We are talking hardware implementation here, and bugs that cannot be fixed
> by a microcode update. You've seen all the discussion of what implications
> for virtual memory memory management such instructions have, plus inter-
> actions with interrupts et al.

Yes, well, I was was being sarcastic. I'm very much in favour of a
design and programming philosphy that strives to make things work
properly before they are deployed in the field. I am aware of how
much work this can entail, and why it is rarely practised.

> An instruction whose semantics force an implementation to execute it
> twice, once doing nothing but checking for possible VM errors and once
> again actually doing the work - and making sure that no page table has
> been changed in the mean time, no interrupt has been handled, ... - is
> broken by design. And designing such instruction such that they don't
> have such broken semantics ain't easy.

I see no reason why you assume _a priori_ that such instructions would
have to be executed twice. However we have not specified the exact
semantics of a machine here, nor the bouds checking (for instance) that
might be necessary. My uneducated predisposition to disliking
microcode is one thing, but I suspect error checking that cannot be
made an integral part of the instruction decode and execution is bound
to fail to win over supporters.

Page faults interrupting an in-progress ranged operation might be
difficult to handle. If the hypothetical CPU supports concurrent
hardware threading, and the OS can guarantee not to stall in the CPU
while swapping under such conditions by virtue of the overall design,
then this is not a show stopper.

But I suspect there are all sorts of interesting ways this particular
problem could be handled. Perhaps the loading of register attributes
could optionally signal the CPU to inform the OS via an exception
callback that it should make sure the requisite pages are in memory or
on their way. Perhaps there is a simple and clever design of a
parallel instruction execution unit that will obviate potential stall
or deadlock risks, or other unanalysed design problems.

> >>Incidentally, the transputer's MOVE instruction supplies a nice lesson in
> >>why such designs are difficult. [war story elided]
> > Microcode updates are much more common these days, and so bugs in the
> > CPU are not quite the problem they once were.
>
> Yes, in this example a fix could have been done in microcode. There are
> similar bugs which cannot be fixed - and the code you field cannot _rely_
> on the processor it is running on having been fixed in the first place,
> so your software workarounds need to execute anyway!

True enough.

Speaking of microcode, prior art, and state of the art, I feel
obligated to say that the ISA microcomputer architectures seem rather
ugly. There are a bunch of things like policy driven bus arbitration ,
timers, hardware context switching and so forth that would be ideal as
small programmable functional units existing independently of the basic
CPU instruction architecture. I'm sure some of this stuff is part of
prior and existing designs, and I would be surprised to learn that
hardware channel arbitration wasn't done with microcode years and years
ago. IBM engineers have probably been doing some of this stuff for
ages. But like other features mentioned previously, some of this stuff
never made it down to the microprocessor world. It's a shame, too,
because I suspect it is _really_ difficult to do decent QOS
provisioning and real-time applications without non-trivial provisions
in the hardware aiding the OS.

With Linux and friends really taking off, I think there is a real need
to provide a more professional environment for those with big
applications. Twenty years from now it will probably be really
affordable to buy a non-trivial n-way parallel desktop machine. It
would suck if the only CPU options were direct decendents of the
unmodified microprocessor architectures of the 1980s CPUs.


Regards,

Steve

.

Relevant Pages

  • Re: Windows XP 64
    ... It could do certain operations in a single instruction ... programmer, ... IBM played the usual game - some so-called hardware features were ... Of course 360 featured microcode, ...
    (rec.audio.pro)
  • Re: Windows XP 64
    ... programmer, you coded one instruction, and from your ... Modify accumulator or register with data from storage or another register ... of the operator or programmer. ... The 360s used microcode, which we now call firmware, not software. ...
    (rec.audio.pro)
  • Re: Thinking assembly?
    ... I simply needs to understand the CPU and how it works, ... > understand the instructions, be a good and experienced programmer, ... assembly language is the machine's language (or, at least, ...
    (alt.lang.asm)
  • Re: [PATCH] x86 - Enhance DEBUG_RODATA support - alternatives
    ... has been pulled out of the x86 tree. ... text_poke required to support this. ... correctly and so the CPU HOTPLUG special case can be removed. ... When you use this code to patch more than one byte of an instruction ...
    (Linux-Kernel)
  • Re: Simple function arguments
    ... are 2 names refering to the same memory location and use that. ... In the internals of a CPU there are various registers. ... address is stored from where the next instruction from memory is read and executed. ... what is generally referred to as 'The stack'. ...
    (comp.lang.cpp)