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

Groups > comp.arch > #114813 > unrolled thread

Combining Practicality with Perfection

Back to article view | Back to comp.arch

Contents

  Combining Practicality with Perfection John Savard <quadibloc@invalid.invalid> - 2026-01-31 18:28 +0000
    Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-01-31 22:36 +0000
    Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-05 01:57 +0000
      Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-05 06:06 +0000
        Re: Combining Practicality with Perfection Robert Finch <robfi680@gmail.com> - 2026-02-05 08:10 -0500
        Re: Combining Practicality with Perfection scott@slp53.sl.home (Scott Lurndal) - 2026-02-05 14:50 +0000
        Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-05 23:58 +0000
          Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-02-06 16:37 +0000
            Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-06 22:32 +0000
              Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-06 22:34 +0000
              Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-07 00:57 +0000
                Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-07 02:45 +0000
            Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-06 22:40 +0000
          Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-09 22:46 +0000
            Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-10 03:49 +0000
              Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-10 19:10 +0000
                Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-11 23:04 +0000
                  Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-11 23:55 +0000
                    Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 06:04 +0000
                    Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-24 00:22 +0000
                      Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-24 19:32 +0000
                      Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-10-25 06:00 +0000
                        Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-25 17:38 +0000
                          Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-10-25 22:43 -0700
                          Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-10-26 09:35 +0000
                            Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-10-26 19:53 +0000
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-26 13:40 +0000
                            Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-26 22:05 +0000
                              Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-26 22:12 +0000
                              Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-10-26 20:13 -0700
                                Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-27 14:30 +0000
                            Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-26 22:09 +0000
                              Re: Combining Practicality with Perfection EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-26 18:20 -0400
                                Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-27 03:00 +0000
                          Re: Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-10-26 22:51 +0000
                        Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-10-25 18:47 +0000
                  Re: Combining Practicality with Perfection David Schultz <david.schultz@earthlink.net> - 2026-02-11 17:57 -0600
                    Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-12 00:04 +0000
                      Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 02:04 +0000
                        Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-12 03:31 +0000
                          Hex floating point (was: Combining Practicality with Perfection) Thomas Koenig <tkoenig@netcologne.de> - 2026-02-15 16:53 +0000
                        Re: Combining Practicality with Perfection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 08:45 +0000
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 17:09 +0000
                            Re: Combining Practicality with Perfection Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-14 18:03 +0100
                            Re: Combining Practicality with Perfection BGB <cr88192@gmail.com> - 2026-02-19 02:10 -0600
                              Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-19 17:30 +0000
                                Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-19 20:15 +0200
                                  Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-19 19:55 +0000
                                Re: Combining Practicality with Perfection BGB <cr88192@gmail.com> - 2026-02-20 05:08 -0600
                                  Re: Combining Practicality with Perfection Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-20 15:22 +0100
                                    Re: Combining Practicality with Perfection BGB <cr88192@gmail.com> - 2026-02-20 15:26 -0600
                                Re: Combining Practicality with Perfection Paul Clayton <paaronclayton@gmail.com> - 2026-02-21 20:27 -0500
                        Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-12 10:49 +0200
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 17:10 +0000
                            Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-12 23:38 +0200
                        Re: Combining Practicality with Perfection Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-12 14:28 +0100
                    Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 05:51 +0000
                    Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-12 10:53 +0200
                      Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 18:40 +0000
                        Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 20:02 +0000
                        Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 20:33 +0000
                  Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-11 19:50 -0800
                    Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 05:55 +0000
                      Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-12 08:40 -0800
                        Re: Combining Practicality with Perfection scott@slp53.sl.home (Scott Lurndal) - 2026-02-12 16:51 +0000
                        Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 18:49 +0000
                    Re: Combining Practicality with Perfection scott@slp53.sl.home (Scott Lurndal) - 2026-02-12 15:54 +0000
                      Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-12 08:52 -0800
                        Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 18:37 +0000
                  Re: Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-14 16:33 +0000
                    Re: floating pain, Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-14 18:12 +0000
                      Re: floating pain, Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 01:16 +0000
                        Re: floating pain, Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-17 01:24 +0000
                          Re: floating pain, Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 16:21 +0000
                            Re: floating pain, Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-17 19:20 +0000
                              Re: floating pain, Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 19:52 +0000
                          Re: floating pain, Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-17 19:09 +0000
                    Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-02-15 14:37 +0000
                      Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-17 18:57 +0000
                        Re: Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 20:43 +0000
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-18 00:50 +0000
                          Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-18 08:52 +0000
                            Re: Combining Practicality with Perfection Robert Finch <robfi680@gmail.com> - 2026-02-18 08:40 -0500
                              Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-20 08:14 +0000
                      Re: Combining Practicality with Perfection Thomas Koenig <tkoenig@netcologne.de> - 2026-02-19 18:49 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#118812

quadibloc@invalid.com (John Savard) posted:

> On Wed, 11 Feb 2026 23:55:29 GMT, MitchAlsup
> <user5857@newsgrouper.org.invalid> wrote:
> 
> >In this case YOU have to ask YOURSELF why are you providing any of those
> >strange data sizes AT ALL ??? That is who is Concertina for ???
> 
> I think that ARM-based smartphones already existed when I started work
> on Concertina II.
> But it may be that it was before Apple switched the Macintosh over to
> Apple Silicon, so ARM was still seen as a niche product.
> 
> So, psychologically, I felt that we were living in a world where,
> essentially, x86 - at least in its x86-64 incarnation - had *killed
> off all other computer architectures*.

Microprocessors killed off minicomputers--no doubt.
Microprocessors did not kill off mainframes--and still cannot (RAS)

> From this, I drew the conclusion that, when it comes to computer
> architectures, "There can be only one" - like Highlander.

{Duncan or Connor} ??

One will never happen, one may become and remain dominant for long
periods of time, but not forever.
 
> And from that, I came to the further conclusion... that if the world
> can have only one computer architecture, then, in order for the world
> not to be impoverished thereby, that one surviving computer
> architecture must be able to "do everything", where "everything"
> includes, say, being able to run PDP-10 code at nearly native speeds.
> Hence, strange data sizes.

Everything I have seen over 50 years tells me "mediocracy first wins".
> 
> John Savard

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

#118820

In article <6adbf8ee.10622140@news.eternal-september.org>,
quadibloc@invalid.com (John Savard) wrote:

> if the world can have only one computer architecture, then, in 
> order for the world not to be impoverished thereby, that one 
> surviving computer architecture must be able to "do everything", 
> where "everything" includes, say, being able to run PDP-10 code 
> at nearly native speeds.

However, an architecture of extreme complexity, burdened with lots of
rarely used features, is most unlikely to become the world's sole
architecture. 

Have you tried running PDP-10 code in an emulator on a modern 64-bit
machine? I'd bet that it significantly exceeds the speed of the native
hardware. 

John 

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

#118823

On Sun, 25 Oct 2026 06:00 +0000 (GMT Standard Time), jgd@cix.co.uk
(John Dallman) wrote:
>In article <6adbf8ee.10622140@news.eternal-september.org>,
>quadibloc@invalid.com (John Savard) wrote:
>
>> if the world can have only one computer architecture, then, in 
>> order for the world not to be impoverished thereby, that one 
>> surviving computer architecture must be able to "do everything", 
>> where "everything" includes, say, being able to run PDP-10 code 
>> at nearly native speeds.
>
>However, an architecture of extreme complexity, burdened with lots of
>rarely used features, is most unlikely to become the world's sole
>architecture. 

True, but I haven't been able to figure out an alternative.

Also, fortunately, my sole competition happens to be struggling under
a burden of its own which seems to be just as great or greater. (That
is, if you don't count ARM and RISC-V...)

>Have you tried running PDP-10 code in an emulator on a modern 64-bit
>machine? I'd bet that it significantly exceeds the speed of the native
>hardware. 

But it doesn't exceed the speed of the modern 64-bit machine.

And? Why does that matter?

It's not enough for people to be able to emulate a PDP-10 for merely
_sentimental_ reasons. I want to breathe life into those dusty decks!

I want there to be other ways of computing!

Even though I remain sedulously unimpressed by the notion that
psilocybin beats empiricsm as a way of knowing.

John Savard

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

#118831

On 10/25/2026 10:38 AM, John Savard wrote:
> On Sun, 25 Oct 2026 06:00 +0000 (GMT Standard Time), jgd@cix.co.uk
> (John Dallman) wrote:
>> In article <6adbf8ee.10622140@news.eternal-september.org>,
>> quadibloc@invalid.com (John Savard) wrote:
>>
>>> if the world can have only one computer architecture, then, in
>>> order for the world not to be impoverished thereby, that one
>>> surviving computer architecture must be able to "do everything",
>>> where "everything" includes, say, being able to run PDP-10 code
>>> at nearly native speeds.
>>
>> However, an architecture of extreme complexity, burdened with lots of
>> rarely used features, is most unlikely to become the world's sole
>> architecture.
> 
> True, but I haven't been able to figure out an alternative.
> 
> Also, fortunately, my sole competition happens to be struggling under
> a burden of its own which seems to be just as great or greater. (That
> is, if you don't count ARM and RISC-V...)
> 
>> Have you tried running PDP-10 code in an emulator on a modern 64-bit
>> machine? I'd bet that it significantly exceeds the speed of the native
>> hardware.
> 
> But it doesn't exceed the speed of the modern 64-bit machine.
> 
> And? Why does that matter?
> 
> It's not enough for people to be able to emulate a PDP-10 for merely
> _sentimental_ reasons. I want to breathe life into those dusty decks!

What exactly does that mean?  You aren't providing an exact match for 
the PDP-10 ISA, so you need some kind of emulator.  Surely no one is 
writing new PDP-10 code, so there isn't a market for that.

> I want there to be other ways of computing!

Again, what does that mean?  If you mean different ISA, there are two 
currently popular ones, RISC 5 seems to be gaining, and I expect that 
Mitch hopes to add to the list.  I suppose you could mean some sort of 
AI/neural net thing, but your architecture shows no signs of that.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#118836

In article <6ade3c57.66203562@news.eternal-september.org>,
quadibloc@invalid.com (John Savard) wrote:

> It's not enough for people to be able to emulate a PDP-10 for merely
> _sentimental_ reasons. I want to breathe life into those dusty 
> decks!

Software that ran on PDP-10s, and other obsolete architectures, which
people or organisations _needed_ has either been re-written for other
architectures by now, or is run under emulation. 

Given that there isn't a commercial emulator for PDP-10, it seems
unlikely to me that there's any significant business advantage to be
gained from a new architecture that emulates it faster. Business
advantage drives processor chip manufacture. 

John 

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

#118848

According to John Dallman <jgd@cix.co.uk>:
>In article <6ade3c57.66203562@news.eternal-september.org>,
>quadibloc@invalid.com (John Savard) wrote:
>
>> It's not enough for people to be able to emulate a PDP-10 for merely
>> _sentimental_ reasons. I want to breathe life into those dusty 
>> decks!
>
>Software that ran on PDP-10s, and other obsolete architectures, which
>people or organisations _needed_ has either been re-written for other
>architectures by now, or is run under emulation. 
>
>Given that there isn't a commercial emulator for PDP-10, it seems
>unlikely to me that there's any significant business advantage to be
>gained from a new architecture that emulates it faster. 

Foonly, XKL, and Systems Concepts built PDP-10 architecture machines
after DEC gave up. As far as I can tell, technically they were fine,
ran all the software faster than the KL, lower power, and used more
modern peripherals, but most PDP-10 users had already moved on.



-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#118838

quadibloc@invalid.com (John Savard) posted:

> On Sun, 25 Oct 2026 06:00 +0000 (GMT Standard Time), jgd@cix.co.uk
> (John Dallman) wrote:
> >In article <6adbf8ee.10622140@news.eternal-september.org>,
> >quadibloc@invalid.com (John Savard) wrote:
> >
> >> if the world can have only one computer architecture, then, in 
> >> order for the world not to be impoverished thereby, that one 
> >> surviving computer architecture must be able to "do everything", 
> >> where "everything" includes, say, being able to run PDP-10 code 
> >> at nearly native speeds.
> >
> >However, an architecture of extreme complexity, burdened with lots of
> >rarely used features, is most unlikely to become the world's sole
> >architecture. 
> 
> True, but I haven't been able to figure out an alternative.
> 
> Also, fortunately, my sole competition happens to be struggling under
> a burden of its own which seems to be just as great or greater. (That
> is, if you don't count ARM and RISC-V...)

But it has multiple companies with hundreds of architects and engineers
(each) working to move them forward. You only have you.
 
> >Have you tried running PDP-10 code in an emulator on a modern 64-bit
> >machine? I'd bet that it significantly exceeds the speed of the native
> >hardware. 
> 
> But it doesn't exceed the speed of the modern 64-bit machine.
> 
> And? Why does that matter?
> 
> It's not enough for people to be able to emulate a PDP-10 for merely
> _sentimental_ reasons. I want to breathe life into those dusty decks!
> 
> I want there to be other ways of computing!
> 
> Even though I remain sedulously unimpressed by the notion that
> psilocybin beats empiricsm as a way of knowing.
> 
> John Savard

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

#118855

On Mon, 26 Oct 2026 13:40:11 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:
>quadibloc@invalid.com (John Savard) posted:

>> Also, fortunately, my sole competition happens to be struggling under
>> a burden of its own which seems to be just as great or greater. (That
>> is, if you don't count ARM and RISC-V...)

>But it has multiple companies with hundreds of architects and engineers
>(each) working to move them forward. You only have you.

Oh, I am well aware of that. I'm not totally deluded!

I've tried to do without block structure, which I admit is off-putting
to many. The current Concertina II includes a means of embedding
48-bit instructions in code without block headers, thus getting most
of the instruction set in without block headers.

What I _can't_ do, though, without block headers without crippling the
instruction set, is to include 16-bit short instructions. The short
instructions wind up nearly useless, and the opcode space left leaves
the memory-reference instructions severely limited.

Obviously, of course, I can avoid that by not having 32 registers.
With 8 registers, the  68020 is an existence proof, and the System/360
proves that even 16 registers will work. But RISC with 32 registers
exists, is popular, and having 32 registers adds performance.

And the more exotic things for which I wish to at least specify
opcodes - like System/360 "Hexadecimal Floating-Point" - are things
that are not part of the basic subset of the architecture.

So to have 32 registers, immediate values in instructions, short
instructions nearly 16 bits in length (17 bits plus 32/15 bits header
overhead), and dumb fast decoding... I need the block structure.

And if I have it, of course, it lets me cheat the Pigeonhole Principle
shamelessly - since, as pointed out, it's mode bits, but mode bits
hackers can't exploit!

John Savard

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

#118857

On Mon, 26 Oct 2026 22:05:30 GMT, quadibloc@invalid.com (John Savard)
wrote:

>Obviously, of course, I can avoid that by not having 32 registers.
>With 8 registers, the  68020 is an existence proof, and the System/360
>proves that even 16 registers will work. But RISC with 32 registers
>exists, is popular, and having 32 registers adds performance.

I may not have exhausted all possible alternatives, though. Concertina
II has 32 registers for regular use - but it has another set of 128
registers (each for integer and floating-point) which require longer
instructions to use them. So I could convince myself that a machine
which uses banks of 8 registers most of the time, but can switch to
128 registers, at the cost of using 48-bit instructions to do that,
could still provide adequate performance.

John Savard

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

#118863

On 10/26/2026 3:05 PM, John Savard wrote:

> And the more exotic things for which I wish to at least specify
> opcodes - like System/360 "Hexadecimal Floating-Point" - are things
> that are not part of the basic subset of the architecture.

At the risk of feeding your obsession . . .

I think you will admit that the use of S/360 floating point will be 
rare.  And let me posit that the need to mix that with IEEE floating 
point in the same program is non-existent.  If that is true, you could 
use the same op codes for both formats and have a global mode that 
specifies which one to use.  This would save some opcodes.  And since in 
practice no one will want the S/360 stuff, make that mode an optional 
feature.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#118867

On Mon, 26 Oct 2026 20:13:18 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>If that is true, you could 
>use the same op codes for both formats and have a global mode that 
>specifies which one to use.

Some hacker might find a way to exploit that!

I'm just using that as an example of the many data types I wish to
offer. But indeed S/360 floating-point support will be optional even
in Concertina II as it is.

John Savard

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

#118856

On Mon, 26 Oct 2026 13:40:11 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

>But it has multiple companies with hundreds of architects and engineers
>(each) working to move them forward. You only have you.

Also...

The way things are going these days, someone is going to leave lying
around under a BSD license the plans for an OoO RISC-V core which, no
doubt, I can modify to execute code for a different instruction set,
even my own.

John Savard

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

#118860

On 2026-Oct-26 18:09, John Savard wrote:
> On Mon, 26 Oct 2026 13:40:11 GMT, MitchAlsup
> <user5857@newsgrouper.org.invalid> wrote:
> 
>> But it has multiple companies with hundreds of architects and engineers
>> (each) working to move them forward. You only have you.
> 
> Also...
> 
> The way things are going these days, someone is going to leave lying
> around under a BSD license the plans for an OoO RISC-V core which, no
> doubt, I can modify to execute code for a different instruction set,
> even my own.
> 
> John Savard

Do you mean like this:

https://opencores.org/projects?expanded=Processor

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

#118862

On Mon, 26 Oct 2026 18:20:51 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:

>Do you mean like this:
>
>https://opencores.org/projects?expanded=Processor

Yes. I found only one out-of-order processor there, though, and it's
in the planning stage.

I had heard of other academic projects to create an out-of-order
RISC-V processor, and there's something called BOOM.

John Savard

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

#118861

John Savard <quadibloc@invalid.com> wrote:
> On Sun, 25 Oct 2026 06:00 +0000 (GMT Standard Time), jgd@cix.co.uk
> (John Dallman) wrote:
>>In article <6adbf8ee.10622140@news.eternal-september.org>,
>>quadibloc@invalid.com (John Savard) wrote:
>>
>>> if the world can have only one computer architecture, then, in 
>>> order for the world not to be impoverished thereby, that one 
>>> surviving computer architecture must be able to "do everything", 
>>> where "everything" includes, say, being able to run PDP-10 code 
>>> at nearly native speeds.
>>
>>However, an architecture of extreme complexity, burdened with lots of
>>rarely used features, is most unlikely to become the world's sole
>>architecture. 
> 
> True, but I haven't been able to figure out an alternative.
> 
> Also, fortunately, my sole competition happens to be struggling under
> a burden of its own which seems to be just as great or greater. (That
> is, if you don't count ARM and RISC-V...)
> 
>>Have you tried running PDP-10 code in an emulator on a modern 64-bit
>>machine? I'd bet that it significantly exceeds the speed of the native
>>hardware. 
> 
> But it doesn't exceed the speed of the modern 64-bit machine.
> 
> And? Why does that matter?
> 
> It's not enough for people to be able to emulate a PDP-10 for merely
> _sentimental_ reasons. I want to breathe life into those dusty decks!
> 
> I want there to be other ways of computing!

Nobody sane will spend serious effort writing PDP-10 assembly.
Note that classic PDP-10 has address space slightly larger
than megabyte, that is seriously inadeqate now.  Extended
addresing allows bigger address space, but why bother when
32 bit and 64 bit machines are widely available.

Look at sorry state of x86_64-32.  This uses 32-bit pointers on
common 64 bit PC-s.  In a sense it is widely available:
there is a lot of hardware, there is Linux kernel and C
compiler.  And theoretically it gives significant advantages,
as long as program fits into 32 bit address space it uses less
storage for pointers and has less data to copy.  IIUC realistic
claim is that programs run 10-20% faster than programs using
64 bit pointers.  Yet a lot of software does not work.
10% faster is too weak motivation to make sure that
programs work.

In slightly different spirit, Python seem now to be most
popular programming language.  Most web servers seem to
run PHP.  Both are dynamically typed and typically use
bytecode interpreters.  On low-level style code statically
typed language compiler to machine code can get 100 times
better speed.  Yet bytecode-compiled dynamically typed
languages are quite popular.

How is this possible?  One thing is that performance critical
code is a small part of all code.  People can and are willing
to spend significant effort to improve speed of small
critical pieces of code.  Say, application needs a lot of 37
bit integers and using more bits would waste space.  One can
write packing and unpacking routines so that say unpacking
routine unpacks 37 words of 64 bits each into 64 word, puting
37 bit integer in each 64-bit word and similar for packing
routine.  If used smartly, this can give computational speed
the same as using 37 bit integers, but memory use of 37
integers.   For addition one can try to put three 37 bit integers
int 2 words and use add with carry.  Not as bit efficient
as dedicated 37 bit adder, but uses 111 bit out of 128,
so is 86% efficient.  And actually, modern machines are
generously equipped into execution units and are more data
bound, so even using full 64 bit arithemetic may be good
enough.

Note that performance of modern machines is statistical.  For
important problems vendors add special instrutions.  If
support for 37 bit integers or 41 bit floats was critical,
then vendors would add special handling.  If for specific
application some nuber size is especially important, then
software can try to do something.  For example, for computing
information about groups one can use coset enumeration.
This may use a lot of memory.  Popular program for doing
this offers use of 40 bit integers.  That is purely software
thing, but runs runs fast enough (probably faster than version
using 64 bit integers) and saves nontrival amount of memory.
Sure, having hardware 40 bit integers would make it faster
and some more saving would be possible if 37 bits are
enough on hardware that supports 37 bit integers.  For
somewhat different mathematical calculation one need
computation in field having 2 to power 60 elements.  So
60 bit integers and special computational instructions
(like carryless mutiplication) would be desirable.  But
computation like this form rather small market and
hardware vendors will not complicate machines to improve
performance for small niche market.

Realistically, what one could hope for are general purpose
extentions which also help in niche cases.  Say, ability to
relatively cheaply load any small size bit string at
arbitrary bit address.  Note that on current machines this
may easily take 20 instructions including conditional jump.
With better instruction set this could be reduced to few
instructions or even one, for example instrucion having
two register arguments and destination, so that first
register is bit address, second is length which loads
bitstring to the destination.

-- 
                              Waldek Hebisch

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

#118825

According to John Dallman <jgd@cix.co.uk>:
>However, an architecture of extreme complexity, burdened with lots of
>rarely used features, is most unlikely to become the world's sole
>architecture. 
>
>Have you tried running PDP-10 code in an emulator on a modern 64-bit
>machine? I'd bet that it significantly exceeds the speed of the native
>hardware. 

The KL-10 was about 1.8 MIPS.  On modern hardware you'd have to write a pretty bad
simulator to run that slow.

I had a lot of fun programming a PDP-10 fifty years ago, but it ran out of address bits
(even the expanded address hack only gave 30 bits, or about 4GB) and the handwriting was
on the wall that only 8 bit byte addressed machines would survive.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#114924

On 2/11/26 5:04 PM, quadi wrote:
> I remember having read one article in a computer magazine where someone
> mentioned that an unfortunate result of the transition from the IBM 7090
> to the IBM System/360 was that a lot of FORTRAN programs that were able to
> use ordinary real nubers had to be switched over to double precision to
> yield acceptable results.

This reminds me of when I took a numerical analysis course. (The many 
ways that computer calculations can go wrong and how to deal with it.) 
The professor said that the schools IBM (360 or 370, ca. 1980) was 
perfect for the course because of the defects in its floating point 
system. Guard digits and rounding sorts of things as near as I can recall.

-- 
http://davesrocketworks.com
David Schultz
"Gag me with a Smurf"

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

#114925

According to David Schultz  <david.schultz@earthlink.net>:
>This reminds me of when I took a numerical analysis course. (The many 
>ways that computer calculations can go wrong and how to deal with it.) 
>The professor said that the schools IBM (360 or 370, ca. 1980) was 
>perfect for the course because of the defects in its floating point 
>system. Guard digits and rounding sorts of things as near as I can recall.

The 360's floating point is a famous and somewhat puzzling failure, considering
how much else they got right.

It does hex normalization rather than binary. They assumed that
leading digits are evenly distributed so there's be on average one
zero bit, but in fact they're geometrically distributed, so on average
there's two. They got one bit back by making the exponent units of 16
rather than 2, but that's still one bit gone. It truncated rather than
rounding, another bit gone.  They also truncated rather than rounding
results.

Originally there wre no guard digits which made the results comically
bad but IBM retrofitted them at great cost to all the installed machines.

IEEE floating point can be seen as a reaction to that, how do you use
the same number of bits but get good results.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#114927

John Levine <johnl@taugh.com> posted:

> According to David Schultz  <david.schultz@earthlink.net>:
> >This reminds me of when I took a numerical analysis course. (The many 
> >ways that computer calculations can go wrong and how to deal with it.) 
> >The professor said that the schools IBM (360 or 370, ca. 1980) was 
> >perfect for the course because of the defects in its floating point 
> >system. Guard digits and rounding sorts of things as near as I can recall.
> 
> The 360's floating point is a famous and somewhat puzzling failure, considering
> how much else they got right.
> 
> It does hex normalization rather than binary. They assumed that
> leading digits are evenly distributed so there's be on average one
> zero bit, but in fact they're geometrically distributed, so on average
> there's two. They got one bit back by making the exponent units of 16
> rather than 2, but that's still one bit gone. It truncated rather than
> rounding, another bit gone.  They also truncated rather than rounding
> results.
> 
> Originally there wre no guard digits which made the results comically
> bad but IBM retrofitted them at great cost to all the installed machines.
> 
> IEEE floating point can be seen as a reaction to that, how do you use
> the same number of bits but get good results.

VAX got this correct too (the VAX format not the one inherited from 
PDP-11/45; PDP-11/40* FP was worse). VAX FP is arguably as good as
IEEE 754 with the exception that more IEEE numbers have reciprocals 
due to the change in exponent bias by 1. {{One can STILL argue whether
deNormals were a plus or a minus in IEEE}}

CMU had a PDP-11/40 with writable control store 1974. I programmed it 
to do PDP-11/45 FP instead of PDP-11/40 FP as a Jr. project.
> 

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

#114929

According to MitchAlsup  <user5857@newsgrouper.org.invalid>:
>
>John Levine <johnl@taugh.com> posted:
>
>> According to David Schultz  <david.schultz@earthlink.net>:
>> >This reminds me of when I took a numerical analysis course. (The many 
>> >ways that computer calculations can go wrong and how to deal with it.) 
>> >The professor said that the schools IBM (360 or 370, ca. 1980) was 
>> >perfect for the course because of the defects in its floating point 
>> >system. Guard digits and rounding sorts of things as near as I can recall.
>> 
>> The 360's floating point is a famous and somewhat puzzling failure, considering
>> how much else they got right.
>> 
>> It does hex normalization rather than binary. They assumed that
>> leading digits are evenly distributed so there's be on average one
>> zero bit, but in fact they're geometrically distributed, so on average
>> there's two. They got one bit back by making the exponent units of 16
>> rather than 2, but that's still one bit gone. It truncated rather than
>> rounding, another bit gone.  They also truncated rather than rounding
>> results.

Oh I forgot that using hex exponents meant there was no hidden bit, so
in practice it lost three bits of precision on every operation.  There was
a great deal of grumbling that people with 709x Fortran codes had to
make everything double precision to keep getting reasonably good results.

>> Originally there wre no guard digits which made the results comically
>> bad but IBM retrofitted them at great cost to all the installed machines.
>> 
>> IEEE floating point can be seen as a reaction to that, how do you use
>> the same number of bits but get good results.
>
>VAX got this correct too (the VAX format not the one inherited from 
>PDP-11/45; PDP-11/40* FP was worse). ...

The VAX is the first machine I know that used the hidden bit trick to
get an extra bit of significance.  The PDP-6/10 was pretty close but
their format was two's complement which meant no hidden bit but they
could use integer comparisons on normalized floating point numbers.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.arch

csiph-web