Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #10155 > unrolled thread

Is MIX utterly silly?

Back to article view | Back to comp.programming

Contents

  Is MIX utterly silly? Peter Percival <peterxpercival@hotmail.com> - 2019-08-19 22:52 +0100
    Re: Is MIX utterly silly? Robert Wessel <robertwessel2@yahoo.com> - 2019-08-19 21:14 -0500
      Re: Is MIX utterly silly? Peter Percival <peterxpercival@hotmail.com> - 2019-08-20 13:15 +0100
        Re: Is MIX utterly silly? David Brown <david.brown@hesbynett.no> - 2019-08-20 14:49 +0200
          Re: Is MIX utterly silly? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-21 07:35 +0200
            Re: Is MIX utterly silly? David Brown <david.brown@hesbynett.no> - 2019-08-21 14:08 +0200
              Re: Is MIX utterly silly? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-21 17:10 +0200
                Re: Is MIX utterly silly? David Brown <david.brown@hesbynett.no> - 2019-08-22 15:11 +0200
            Re: Is MIX utterly silly? Louis Valence <lvalence@example.com> - 2019-08-23 17:13 -0300
              Re: Is MIX utterly silly? Peter Percival <peterxpercival@hotmail.com> - 2019-08-24 20:53 +0100
                Re: Is MIX utterly silly? luser droog <mijoryx@yahoo.com> - 2019-09-08 12:50 -0700
        Re: Is MIX utterly silly? Louis Valence <lvalence@example.com> - 2019-08-23 17:01 -0300

#10155 — Is MIX utterly silly?

That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly 
regarded, but MIX is an April fool's joke, isn't it?  (Fool's/fools' not 
sure which.)

[toc] | [next] | [standalone]

#10156

On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
<peterxpercival@hotmail.com> wrote:

>That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly 
>regarded, but MIX is an April fool's joke, isn't it?  (Fool's/fools' not 
>sure which.)


No, it's not.  But he has come up with a more modern ISA (RISC-ish)
for newer editions of the books, MMIX.

He offers a justification for MIX in the beginning of volume 1.

[toc] | [prev] | [next] | [standalone]

#10157

Robert Wessel wrote:
> On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
> <peterxpercival@hotmail.com> wrote:
> 
>> That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly
>> regarded, but MIX is an April fool's joke, isn't it?  (Fool's/fools' not
>> sure which.)
> 
> 
> No, it's not.  But he has come up with a more modern ISA (RISC-ish)
> for newer editions of the books, MMIX.
> 
> He offers a justification for MIX in the beginning of volume 1.

I find it unconvincing!
> 

[toc] | [prev] | [next] | [standalone]

#10158

On 20/08/2019 14:15, Peter Percival wrote:
> Robert Wessel wrote:
>> On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
>> <peterxpercival@hotmail.com> wrote:
>>
>>> That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly
>>> regarded, but MIX is an April fool's joke, isn't it?  (Fool's/fools' not
>>> sure which.)
>>
>>
>> No, it's not.  But he has come up with a more modern ISA (RISC-ish)
>> for newer editions of the books, MMIX.
>>
>> He offers a justification for MIX in the beginning of volume 1.
> 
> I find it unconvincing!

Me too.  The MIX is a hideous design, totally at odds with its purpose.
 MMIX is better, but still pointlessly restricted and overly complicated.

For the purposes of demonstrating algorithms or calculating complexity,
there is little reason to have an assembly at all - a low level language
for an abstract machine would be better.  An unlimited register bank
with unlimited sized registers would be more useful.  Any limitations in
the artificial machine would be completely arbitrary - making the
algorithms in the book far more complicated than necessary, and failing
to match real systems.

The result of the MIX and MMIX designs is that most readers gloss over
the MIX programs in the book without a second glance - it's easier to
work from the text and the mathematics than to try to comprehend the MIX
nonsense and then translate it into something useful on real computers.

I'm a Knuth fan and admirer, with volumes 1 to 3 on my bookshelf as well
as a well-read TeXBook (I had the METAFONTbook too, but I seem to have
lost it).  But MIX was a big mistake.  IMHO, of course.

[toc] | [prev] | [next] | [standalone]

#10159

On 20.08.2019 14:49, David Brown wrote:
> On 20/08/2019 14:15, Peter Percival wrote:
>> Robert Wessel wrote:
>>> On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
>>> <peterxpercival@hotmail.com> wrote:
>>>
>>>> That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly
>>>> regarded, but MIX is an April fool's joke, isn't it?  (Fool's/fools' not
>>>> sure which.)
>>>
>>>
>>> No, it's not.  But he has come up with a more modern ISA (RISC-ish)
>>> for newer editions of the books, MMIX.
>>>
>>> He offers a justification for MIX in the beginning of volume 1.
>>
>> I find it unconvincing!
> 
> Me too.  The MIX is a hideous design, totally at odds with its purpose.
>   MMIX is better, but still pointlessly restricted and overly complicated.
> 
> For the purposes of demonstrating algorithms or calculating complexity,
> there is little reason to have an assembly at all - a low level language
> for an abstract machine would be better.  An unlimited register bank
> with unlimited sized registers would be more useful.  Any limitations in
> the artificial machine would be completely arbitrary - making the
> algorithms in the book far more complicated than necessary, and failing
> to match real systems.
> 
> The result of the MIX and MMIX designs is that most readers gloss over
> the MIX programs in the book without a second glance - it's easier to
> work from the text and the mathematics than to try to comprehend the MIX
> nonsense and then translate it into something useful on real computers.
> 
> I'm a Knuth fan and admirer, with volumes 1 to 3 on my bookshelf as well
> as a well-read TeXBook (I had the METAFONTbook too, but I seem to have
> lost it).  But MIX was a big mistake.  IMHO, of course.

It was a child of its time.

One nice thing was that it worked with both decimal and binary. Another 
that it didn't directly support any particular calling convention. I 
remember reacting to one (possibly the first) calling convention he 
exemplified, that of the caller storing the return address in the called 
routine's return instruction...

I once interviewed at Norsk Regnesentral (near Oslo) and they asked me 
why I wanted to work there. Well, when I saw the ad I was reminded of 
Knuth, that he started his books there. I didn't get past explaining 
that, to the part about also being reminded of the Simula work, because 
they were completely perplexed: “Knut?!?”. They then paid for a second 
interview round with a former captain of one of the coast guard ships, 
now employed by a recruiting bureau. He was extremely adversarial, 
focusing on my smoking (this was before I forgot to smoke, and quit) and 
my sex life, or possibly lack of it. I didn't get the job. Strange.

And so it goes.

The world evolves, and so do we, but sloooowly.


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#10160

On 21/08/2019 07:35, Alf P. Steinbach wrote:
> On 20.08.2019 14:49, David Brown wrote:
>> On 20/08/2019 14:15, Peter Percival wrote:
>>> Robert Wessel wrote:
>>>> On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
>>>> <peterxpercival@hotmail.com> wrote:
>>>>
>>>>> That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly
>>>>> regarded, but MIX is an April fool's joke, isn't it? 
>>>>> (Fool's/fools' not
>>>>> sure which.)
>>>>
>>>>
>>>> No, it's not.  But he has come up with a more modern ISA (RISC-ish)
>>>> for newer editions of the books, MMIX.
>>>>
>>>> He offers a justification for MIX in the beginning of volume 1.
>>>
>>> I find it unconvincing!
>>
>> Me too.  The MIX is a hideous design, totally at odds with its purpose.
>>   MMIX is better, but still pointlessly restricted and overly
>> complicated.
>>
>> For the purposes of demonstrating algorithms or calculating complexity,
>> there is little reason to have an assembly at all - a low level language
>> for an abstract machine would be better.  An unlimited register bank
>> with unlimited sized registers would be more useful.  Any limitations in
>> the artificial machine would be completely arbitrary - making the
>> algorithms in the book far more complicated than necessary, and failing
>> to match real systems.
>>
>> The result of the MIX and MMIX designs is that most readers gloss over
>> the MIX programs in the book without a second glance - it's easier to
>> work from the text and the mathematics than to try to comprehend the MIX
>> nonsense and then translate it into something useful on real computers.
>>
>> I'm a Knuth fan and admirer, with volumes 1 to 3 on my bookshelf as well
>> as a well-read TeXBook (I had the METAFONTbook too, but I seem to have
>> lost it).  But MIX was a big mistake.  IMHO, of course.
> 
> It was a child of its time.
> 

It shouldn't have been.  Knuth was better than that.

> One nice thing was that it worked with both decimal and binary. Another
> that it didn't directly support any particular calling convention.

None of that kind of detail should have been relevant.  The abstraction
level is all wrong for a book covering algorithms.

> I
> remember reacting to one (possibly the first) calling convention he
> exemplified, that of the caller storing the return address in the called
> routine's return instruction...

In the early days of computing, there were a variety of methods used for
handling subroutine returns.  I think one of the first one was something
like:

	return:
		goto
		.dataw
	sub:
		... subroutine code ...
		goto return

Calling was:
		... main code ...
		store "next" in "sub - 2"
		goto sub
	next:
		... rest of code ...

So the return address was not stored in the return instruction, but an
extra jump instruction that preceded the subroutine.  This had the
advantage of only needing a single address for the linking stage, but
meant returns needed an extra jump.

> 
> I once interviewed at Norsk Regnesentral (near Oslo) and they asked me
> why I wanted to work there. Well, when I saw the ad I was reminded of
> Knuth, that he started his books there. I didn't get past explaining
> that, to the part about also being reminded of the Simula work, because
> they were completely perplexed: “Knut?!?”. They then paid for a second
> interview round with a former captain of one of the coast guard ships,
> now employed by a recruiting bureau. He was extremely adversarial,
> focusing on my smoking (this was before I forgot to smoke, and quit) and
> my sex life, or possibly lack of it. I didn't get the job. Strange.
> 
> And so it goes.
> 
> The world evolves, and so do we, but sloooowly.
> 

True.  And contrary to common misconceptions, evolution does not
necessarily mean positive progress!

[toc] | [prev] | [next] | [standalone]

#10161

On 21.08.2019 14:08, David Brown wrote:
> On 21/08/2019 07:35, Alf P. Steinbach wrote:
>> On 20.08.2019 14:49, David Brown wrote:
>>> On 20/08/2019 14:15, Peter Percival wrote:
>>>> Robert Wessel wrote:
>>>>> On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
>>>>> <peterxpercival@hotmail.com> wrote:
>>>>>
>>>>>> That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly
>>>>>> regarded, but MIX is an April fool's joke, isn't it?
>>>>>> (Fool's/fools' not
>>>>>> sure which.)
>>>>>
>>>>>
>>>>> No, it's not.  But he has come up with a more modern ISA (RISC-ish)
>>>>> for newer editions of the books, MMIX.
>>>>>
>>>>> He offers a justification for MIX in the beginning of volume 1.
>>>>
>>>> I find it unconvincing!
>>>
>>> Me too.  The MIX is a hideous design, totally at odds with its purpose.
>>>    MMIX is better, but still pointlessly restricted and overly
>>> complicated.
>>>
>>> For the purposes of demonstrating algorithms or calculating complexity,
>>> there is little reason to have an assembly at all - a low level language
>>> for an abstract machine would be better.  An unlimited register bank
>>> with unlimited sized registers would be more useful.  Any limitations in
>>> the artificial machine would be completely arbitrary - making the
>>> algorithms in the book far more complicated than necessary, and failing
>>> to match real systems.
>>>
>>> The result of the MIX and MMIX designs is that most readers gloss over
>>> the MIX programs in the book without a second glance - it's easier to
>>> work from the text and the mathematics than to try to comprehend the MIX
>>> nonsense and then translate it into something useful on real computers.
>>>
>>> I'm a Knuth fan and admirer, with volumes 1 to 3 on my bookshelf as well
>>> as a well-read TeXBook (I had the METAFONTbook too, but I seem to have
>>> lost it).  But MIX was a big mistake.  IMHO, of course.
>>
>> It was a child of its time.
>>
> 
> It shouldn't have been.  Knuth was better than that.
> 
>> One nice thing was that it worked with both decimal and binary. Another
>> that it didn't directly support any particular calling convention.
> 
> None of that kind of detail should have been relevant.  The abstraction
> level is all wrong for a book covering algorithms.

Today.

At the time, pre 1970, there weren't that many higher level languages to 
choose from. He /could/ have tried Simula, but it was another luminary, 
Alan Kay, that got into that. I think at the time Algol still had all 
sorts of deficiencies including "call by name", where due to a simple 
editing error in the spec the compiler had to implement thunks passed 
down to the routine so it could evaluate an argument expression as if in 
the caller's stack frame... To complicated for TAOCPP. I think.

:)


>> I
>> remember reacting to one (possibly the first) calling convention he
>> exemplified, that of the caller storing the return address in the called
>> routine's return instruction...
> 
> In the early days of computing, there were a variety of methods used for
> handling subroutine returns.  I think one of the first one was something
> like:
> 
> 	return:
> 		goto
> 		.dataw
> 	sub:
> 		... subroutine code ...
> 		goto return
> 
> Calling was:
> 		... main code ...
> 		store "next" in "sub - 2"
> 		goto sub
> 	next:
> 		... rest of code ...
> 
> So the return address was not stored in the return instruction, but an
> extra jump instruction that preceded the subroutine.  This had the
> advantage of only needing a single address for the linking stage, but
> meant returns needed an extra jump.
> 
>>
>> I once interviewed at Norsk Regnesentral (near Oslo) and they asked me
>> why I wanted to work there. Well, when I saw the ad I was reminded of
>> Knuth, that he started his books there. I didn't get past explaining
>> that, to the part about also being reminded of the Simula work, because
>> they were completely perplexed: “Knut?!?”. They then paid for a second
>> interview round with a former captain of one of the coast guard ships,
>> now employed by a recruiting bureau. He was extremely adversarial,
>> focusing on my smoking (this was before I forgot to smoke, and quit) and
>> my sex life, or possibly lack of it. I didn't get the job. Strange.
>>
>> And so it goes.
>>
>> The world evolves, and so do we, but sloooowly.
>>
> 
> True.  And contrary to common misconceptions, evolution does not
> necessarily mean positive progress!

Consider, in 1970 it was just 14 years since 1956, when segregation on 
buses was outlawed in the United States, and Norway finally admitted 
Jesuits to the country.

In the 1990s someplace the last canton in Switzerland allowed women to vote.

This was all amazing progress in the timeframe of TAOCPP: treating 
blacks like people, then treating even women like people.

Today we think of the US war on women, where e.g. roughly 7 women 
needlessly die per day in Kenya because the US refuses to fund help 
organizations that fight HIV if they also provide sex and abortion 
information to women, as barbaric -- and that's real progress, that we 
now value lives and life more than the old religious based morals.

Also, in the last few years I've become a better hobby guitarist and a 
better hobby photographer, still so-so as a hobby programmer, but. ;-)


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#10165

On 21/08/2019 17:10, Alf P. Steinbach wrote:
> On 21.08.2019 14:08, David Brown wrote:
>> On 21/08/2019 07:35, Alf P. Steinbach wrote:

>>> It was a child of its time.
>>>
>>
>> It shouldn't have been.  Knuth was better than that.
>>
>>> One nice thing was that it worked with both decimal and binary. Another
>>> that it didn't directly support any particular calling convention.
>>
>> None of that kind of detail should have been relevant.  The abstraction
>> level is all wrong for a book covering algorithms.
> 
> Today.
> 
> At the time, pre 1970, there weren't that many higher level languages to
> choose from. He /could/ have tried Simula, but it was another luminary,
> Alan Kay, that got into that. I think at the time Algol still had all
> sorts of deficiencies including "call by name", where due to a simple
> editing error in the spec the compiler had to implement thunks passed
> down to the routine so it could evaluate an argument expression as if in
> the caller's stack frame... To complicated for TAOCPP. I think.
> 
> :)

There was no need to use an existing language - or even a complete or
real language, or even one that could be implemented practically.  It is
up to the book's reader to translate the algorithm into whatever
language they need at the time.  The programs in the book are for
demonstration and teaching purposes.

>>>
>>> The world evolves, and so do we, but sloooowly.
>>>
>>
>> True.  And contrary to common misconceptions, evolution does not
>> necessarily mean positive progress!
> 
> Consider, in 1970 it was just 14 years since 1956, when segregation on
> buses was outlawed in the United States, and Norway finally admitted
> Jesuits to the country.
> 
> In the 1990s someplace the last canton in Switzerland allowed women to
> vote.
> 
> This was all amazing progress in the timeframe of TAOCPP: treating
> blacks like people, then treating even women like people.
> 
> Today we think of the US war on women, where e.g. roughly 7 women
> needlessly die per day in Kenya because the US refuses to fund help
> organizations that fight HIV if they also provide sex and abortion
> information to women, as barbaric -- and that's real progress, that we
> now value lives and life more than the old religious based morals.
> 

Unfortunately, whenever an issue involves politics, religion or culture
(and this one involves all of them), there is never a consensus on what
"we think".  The reason the US still refuses to support organisations
that mention the word "abortion" or suggest anything other than
abstinence for family planning, is because /they/ think differently.
(By "they", I mean "the powers that be" in the USA, rather than any
individual American.)

Do we really want this thread to be about politics, nations, religion,
or the like?

> Also, in the last few years I've become a better hobby guitarist and a
> better hobby photographer, still so-so as a hobby programmer, but. ;-)
> 
> 
> Cheers!,
> 
> - Alf

[toc] | [prev] | [next] | [standalone]

#10167

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

> On 20.08.2019 14:49, David Brown wrote:

[...]

>> [...] But MIX was a big mistake.  IMHO, of course.
>
> It was a child of its time.

Nothing is ever immune to that, but the purpose of MIX was precisely not
to be a child of its time.  ``My books focus on timeless truths.''

--8<---------------cut here---------------start------------->8---
Why have a machine language?

Many readers are no doubt thinking, ``Why does Knuth replace MIX by
another machine instead of just sticking to a high-level programming
language? Hardly anybody uses assemblers these days.''

Such people are entitled to their opinions, and they need not bother
reading the machine-language parts of my books. But the reasons for
machine language that I gave in the preface to Volume 1, written in the
early 1960s, remain valid today:

    One of the principal goals of my books is to show how high-level
    constructions are actually implemented in machines, not simply to
    show how they are applied. I explain coroutine linkage, tree
    structures, random number generation, high-precision arithmetic,
    radix conversion, packing of data, combinatorial searching,
    recursion, etc., from the ground up.  The programs needed in my
    books are generally so short that their main points can be grasped
    easily.  People who are more than casually interested in computers
    should have at least some idea of what the underlying hardware is
    like. Otherwise the programs they write will be pretty weird.
    Machine language is necessary in any case, as output of many of the
    software programs I describe.  Expressing basic methods like
    algorithms for sorting and searching in machine language makes it
    possible to carry out meaningful studies of the effects of cache and
    RAM size and other hardware characteristics (memory speed,
    pipelining, multiple issue, lookaside buffers, the size of cache
    blocks, etc.) when comparing different schemes.

Moreover, if I did use a high-level language, what language should it
be? In the 1960s I would probably have chosen Algol W; in the 1970s, I
would then have had to rewrite my books using Pascal; in the 1980s, I
would surely have changed everything to C; in the 1990s, I would have
had to switch to C++ and then probably to Java. In the 2000s, yet
another language will no doubt be de rigueur. I cannot afford the time
to rewrite my books as languages go in and out of fashion; languages
aren't the point of my books, the point is rather what you can do in
your favorite language. My books focus on timeless truths.

Therefore I will continue to use English as the high-level language in
TAOCP, and I will continue to use a low-level language to indicate how
machines actually compute. Readers who only want to see algorithms that
are already packaged in a plug-in way, using a trendy language, should
buy other people's books.

The good news is that programming for RISC machines is pleasant and
simple, when the RISC machine has a nice clean design. So I need not
dwell on arcane, fiddly little details that distract from the main
points. In this respect MMIX will be significantly better than MIX.

Source:
https://www-cs-faculty.stanford.edu/~knuth/mmix.html
--8<---------------cut here---------------end--------------->8---

[toc] | [prev] | [next] | [standalone]

#10168

Louis Valence wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> 
>> On 20.08.2019 14:49, David Brown wrote:
> 
> [...]
> 
>>> [...] But MIX was a big mistake.  IMHO, of course.
>>
>> It was a child of its time.
> 
> Nothing is ever immune to that, but the purpose of MIX was precisely not
> to be a child of its time.  ``My books focus on timeless truths.''
> 
> --8<---------------cut here---------------start------------->8---
> Why have a machine language?
> 
> Many readers are no doubt thinking, ``Why does Knuth replace MIX by
> another machine instead of just sticking to a high-level programming
> language? Hardly anybody uses assemblers these days.''
> 
> Such people are entitled to their opinions, and they need not bother
> reading the machine-language parts of my books. But the reasons for
> machine language that I gave in the preface to Volume 1, written in the
> early 1960s, remain valid today:
> 
>      One of the principal goals of my books is to show how high-level
>      constructions are actually implemented in machines, not simply to
>      show how they are applied. I explain coroutine linkage, tree
>      structures, random number generation, high-precision arithmetic,
>      radix conversion, packing of data, combinatorial searching,
>      recursion, etc., from the ground up.  The programs needed in my
>      books are generally so short that their main points can be grasped
>      easily.  People who are more than casually interested in computers
>      should have at least some idea of what the underlying hardware is
>      like.

I agree!  But no computer is or was like MIX.

>      Otherwise the programs they write will be pretty weird.
>      Machine language is necessary in any case, as output of many of the
>      software programs I describe.  Expressing basic methods like
>      algorithms for sorting and searching in machine language makes it
>      possible to carry out meaningful studies of the effects of cache and
>      RAM size and other hardware characteristics (memory speed,
>      pipelining, multiple issue, lookaside buffers, the size of cache
>      blocks, etc.) when comparing different schemes.
> 
> Moreover, if I did use a high-level language, what language should it
> be? In the 1960s I would probably have chosen Algol W; in the 1970s, I
> would then have had to rewrite my books using Pascal; in the 1980s, I
> would surely have changed everything to C; in the 1990s, I would have
> had to switch to C++ and then probably to Java. In the 2000s, yet
> another language will no doubt be de rigueur. I cannot afford the time
> to rewrite my books as languages go in and out of fashion; languages
> aren't the point of my books, the point is rather what you can do in
> your favorite language. My books focus on timeless truths.
> 
> Therefore I will continue to use English as the high-level language in
> TAOCP, and I will continue to use a low-level language to indicate how
> machines actually compute. Readers who only want to see algorithms that
> are already packaged in a plug-in way, using a trendy language, should
> buy other people's books.
> 
> The good news is that programming for RISC machines is pleasant and
> simple, when the RISC machine has a nice clean design. So I need not
> dwell on arcane, fiddly little details that distract from the main
> points. In this respect MMIX will be significantly better than MIX.
> 
> Source:
> https://www-cs-faculty.stanford.edu/~knuth/mmix.html
> --8<---------------cut here---------------end--------------->8---
> 

[toc] | [prev] | [next] | [standalone]

#10185

On Saturday, August 24, 2019 at 2:53:42 PM UTC-5, Peter Percival wrote:
> Louis Valence wrote:
[Knuth:]
> > 
> >      One of the principal goals of my books is to show how high-level
> >      constructions are actually implemented in machines, not simply to
> >      show how they are applied. I explain coroutine linkage, tree
> >      structures, random number generation, high-precision arithmetic,
> >      radix conversion, packing of data, combinatorial searching,
> >      recursion, etc., from the ground up.  The programs needed in my
> >      books are generally so short that their main points can be grasped
> >      easily.  People who are more than casually interested in computers
> >      should have at least some idea of what the underlying hardware is
> >      like.
> 
> I agree!  But no computer is or was like MIX.
> 

Yes, there most certainly were. Even weird stuff like saving the return
address in the subroutine's 'return' instruction, this was done on the
PDP-1. A good source for the wide diversity of 60s and 70s computers
is Bell and Howell, Computer Structures. 

MIX is of course a "mix" of features from various old machines, so
it isn't exactly like any of them. But every weird thing it does is
a reflection of some actual hardware that really did exist.

[toc] | [prev] | [next] | [standalone]

#10166

Peter Percival <peterxpercival@hotmail.com> writes:

> Robert Wessel wrote:
>> On Mon, 19 Aug 2019 22:52:54 +0100, Peter Percival
>> <peterxpercival@hotmail.com> wrote:
>>
>>> That's MIX as in vol 1 of AoCP.  I know Knuth and his books are highly
>>> regarded, but MIX is an April fool's joke, isn't it?  (Fool's/fools' not
>>> sure which.)
>>
>>
>> No, it's not.  But he has come up with a more modern ISA (RISC-ish)
>> for newer editions of the books, MMIX.
>>
>> He offers a justification for MIX in the beginning of volume 1.
>
> I find it unconvincing!

Why?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web