Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

May you do Good Magic with Perl. -- Larry Wall's blessing


devel / comp.arch / Re: tiny little computers, was Upcoming DFP support in clang/LLVM

SubjectAuthor
* Upcoming DFP support in clang/LLVMIvan Godard
+* Re: Upcoming DFP support in clang/LLVMQuadibloc
|`* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| +* Re: Upcoming DFP support in clang/LLVMJohn Levine
| |+* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||`* Re: Upcoming DFP support in clang/LLVMJohn Levine
| || +- Re: Upcoming DFP support in clang/LLVMQuadibloc
| || `* Re: Upcoming DFP support in clang/LLVMJohn Dallman
| ||  `* Re: Upcoming DFP support in clang/LLVMBGB
| ||   `* Re: Upcoming DFP support in clang/LLVMJohn Dallman
| ||    `* Re: Upcoming DFP support in clang/LLVMBGB
| ||     +* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||     |`* Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| ||     | `* Re: Upcoming DFP support in clang/LLVMTim Rentsch
| ||     |  +- Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||     |  `* Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| ||     |   `- Re: Upcoming DFP support in clang/LLVMBGB
| ||     `- Re: Upcoming DFP support in clang/LLVMJohn Dallman
| |+- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| |`* Re: Upcoming DFP support in clang/LLVMBGB
| | +- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | +* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | `* Architecture comparison (was: Upcoming DFP support in clang/LLVM)Anton Ertl
| | | |  `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   +* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Bill Findlay
| | | |   |`* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   | `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |  `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   |   +* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Ivan Godard
| | | |   |   |`- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |   `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |    +- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   |    `* Re: Architecture comparisonTerje Mathisen
| | | |   |     +- Re: Architecture comparisonBGB
| | | |   |     +* Re: Architecture comparisonThomas Koenig
| | | |   |     |`- Re: Architecture comparisonMitchAlsup
| | | |   |     `* Re: Architecture comparisonMichael S
| | | |   |      `* Re: Architecture comparisonMitchAlsup
| | | |   |       +- Re: Architecture comparisonBGB
| | | |   |       `- Re: Architecture comparisonMichael S
| | | |   `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |    `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Quadibloc
| | | |     `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Stephen Fuld
| | | |      `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |       `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Stephen Fuld
| | | |        `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |         +- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)John Dallman
| | | |         `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Robert Swindells
| | | |          `- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Torbjorn Lindgren
| | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | `- Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | +* Re: Upcoming DFP support in clang/LLVMStephen Fuld
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | | |`- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | | | `* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |  +* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | | |  |+- Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |  |`- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | | |  +- Re: Upcoming DFP support in clang/LLVMrobf...@gmail.com
| | | |  `- Re: Upcoming DFP support in clang/LLVMBGB
| | | +- Re: Graphics in the old days, wasUpcoming DFP support in clang/LLVMJohn Levine
| | | `- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | |`* Re: Upcoming DFP support in clang/LLVMBill Findlay
| | | +- Re: Upcoming DFP support in clang/LLVMIvan Godard
| | | `* Re: Upcoming DFP support in clang/LLVMBrian G. Lucas
| | |  `- Re: Upcoming DFP support in clang/LLVMBill Findlay
| | +- Re: Upcoming DFP support in clang/LLVMStephen Fuld
| | +* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| | |`* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | | `* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| | |  +* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMJohn Levine
| | |  |`* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMMitchAlsup
| | |  | `* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMThomas Koenig
| | |  |  `- Re: Fortran archaeology, Upcoming DFP support in clang/LLVMMitchAlsup
| | |  `- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |  `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMaph
| |   |`* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   | `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBill Findlay
| |   |  |`* Re: tiny little computers, was Upcoming DFP support in clang/LLVMIvan Godard
| |   |  | `- Re: tiny little pages, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  +- Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   |  +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMMitchAlsup
| |   |  |`- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMEricP
| |   |   `- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   +- Re: tiny little computers, was Upcoming DFP support in clang/LLVMRobert Swindells
| |   `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMEricP
| |    `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBill Findlay
| |     `- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| +- Re: Upcoming DFP support in clang/LLVMGuillaume
| `* Re: Upcoming DFP support in clang/LLVMThomas Koenig
|  `* Re: Upcoming DFP support in clang/LLVMThomas Koenig
`* Re: Upcoming DFP support in clang/LLVMMichael S

Pages:12345
Re: Upcoming DFP support in clang/LLVM

<76b92759-e3ba-4f28-a637-b6c848b8597fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25050&group=comp.arch#25050

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:d87:b0:67b:311c:ecbd with SMTP id q7-20020a05620a0d8700b0067b311cecbdmr15328862qkl.146.1651660143111;
Wed, 04 May 2022 03:29:03 -0700 (PDT)
X-Received: by 2002:a4a:ac45:0:b0:35e:a8f2:7f55 with SMTP id
q5-20020a4aac45000000b0035ea8f27f55mr7079911oon.46.1651660142867; Wed, 04 May
2022 03:29:02 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 4 May 2022 03:29:02 -0700 (PDT)
In-Reply-To: <t4t5ha$c8v$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=87.68.182.229; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 87.68.182.229
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4qe9n$vim$1@newsreader4.netcologne.de>
<t4t5ha$c8v$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <76b92759-e3ba-4f28-a637-b6c848b8597fn@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: already5...@yahoo.com (Michael S)
Injection-Date: Wed, 04 May 2022 10:29:03 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 48
 by: Michael S - Wed, 4 May 2022 10:29 UTC

On Wednesday, May 4, 2022 at 9:13:01 AM UTC+3, Thomas Koenig wrote:
> Thomas Koenig <tko...@netcologne.de> schrieb:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> >> On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
> >>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
> >>> > https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
> >>>
> >>> According to that, the project has just begun.
> >>>
> >>> It is reasonable that this project _should_ begin, given that the current C standard has
> >>> provision for DFP, and there are some machines out there with DFP support.
> >><
> >> Representing 0.000,1% of chips containing CPUs; sold annually.
> >
> > Nice floating point format :-)
> >
> > Are there any sources for the number of POWER processors sold
> > these days?
>
>
> I did some digging. Apparently, IBM is selling around 2
> billion dollar's worth of POWER systems per year, according to
> https://www.itjungle.com/2022/03/07/the-low-down-on-ibms-power-systems-sales/
> compared to a total server market of around 20 billion
> (https://www.idc.com/getdoc.jsp?containerId=prUS48221821).

23.6B per Quarter!

> zSystems come to 1.6 Billion (ballpark) at
> https://www.statista.com/statistics/799064/worldwide-revenue-ibm-system-z-mainframe/
>
> So, I'd say that DFP hardware has something like 15% of current
> server markets. Of course, grabbing random data samples from
> the Internet may well be comparing apples to oranges.

Total server market, as estimated by Gartner, is more like 100B USD per year.
That's, according to my understanding, not including servers that hyperscalers order from ODMs.
We can only guess the size of this chunk. My guess is 20 to 30 BUSD per year.
Intel Data Center Division alone reported revenue of $25.8 billion. And that just Intel, which during this period was losing market share to AMD, and mostly, while not only, sells CPUs which constitute, may be, 1/3rd to 1/5th of the total server price.

IBM (Power+z+infrastructure) tends to be 5 to 6% of visible part of server market by value. So, probably 4% by value if we add invisible part.

But it does not mean that 4% of server cores are z+POWER, not even close.
#cores per dollar is far from equal for different vendors.
ARM cores* deliver max. # of cores per dollar, followed by AMD, followed by Intel, followed by IBM POWER sold with Linux,
followed by IBM POWER sold with IBM OSes, followed, with very big gap, by IBM z.

* - mostly in form Amazon's private Graviton2 CPU based on Arm Inc. N1 core, but Graviton3 is coming. Other Arm server vendors make significant noise, but most likely not a significant sales volumes.

Re: Upcoming DFP support in clang/LLVM

<a8feb609-f4b5-458d-8697-146c8492eeb0n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25051&group=comp.arch#25051

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:a44:b0:6a0:aa6:801b with SMTP id j4-20020a05620a0a4400b006a00aa6801bmr3707545qka.152.1651662041830;
Wed, 04 May 2022 04:00:41 -0700 (PDT)
X-Received: by 2002:a05:6870:a2d4:b0:ec:4d5d:d676 with SMTP id
w20-20020a056870a2d400b000ec4d5dd676mr3552403oak.125.1651662041616; Wed, 04
May 2022 04:00:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 4 May 2022 04:00:41 -0700 (PDT)
In-Reply-To: <t4t3ho$bi3$2@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:b917:79aa:ed92:33fd;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:b917:79aa:ed92:33fd
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <t4sgn4$19f$1@dont-email.me> <t4spai$n08$1@dont-email.me>
<b24676b2-b8a9-4dfb-9cf9-18a15b362858n@googlegroups.com> <t4t3ho$bi3$2@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a8feb609-f4b5-458d-8697-146c8492eeb0n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Wed, 04 May 2022 11:00:41 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 19
 by: Quadibloc - Wed, 4 May 2022 11:00 UTC

On Tuesday, May 3, 2022 at 11:39:07 PM UTC-6, Thomas Koenig wrote:

> Doesn't NTSC stand for "Never The Same Color"?

No, it stands for National Television Standards Committee. However, it
was indeed susceptible to phase shift issues, which was what had led
to the Europeans investigating ways to mitigate them, leading to PAL
(Phase Alternation Line) and SECAM (Système Électronique Couleur Avec Mémoire).

There was an interesting article about all this in the March 22, 1965
issue of _Electronics_ magazine, which is available online here:

https://worldradiohistory.com/Electronics%20_Master_Page.htm

The article does note that jokingly NTSC was referred to as Never Twice the
Same Color, SECAM as Something Essentially Contrary to the American Method,
and PAL as Peace At Last.

John Savard

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4tttv$778$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25052&group=comp.arch#25052

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: rjs...@fdy2.co.uk (Robert Swindells)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 13:09:19 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <t4tttv$778$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4s5b4$15n4$2@gal.iecc.com> <t4tei5$sli$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 4 May 2022 13:09:19 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="9d9b9042afac8063f792ce5c7385633c";
logging-data="7400"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NO9V9fJNsM8QClTWZ34+ihcQT+T9FHDg="
User-Agent: Pan/0.150 (Moucherotte; 4c6043e)
Cancel-Lock: sha1:QVVs5hDXHx98UP1OFBig5cz+X20=
 by: Robert Swindells - Wed, 4 May 2022 13:09 UTC

On Wed, 4 May 2022 03:46:51 -0500, BGB wrote:

> On 5/3/2022 4:03 PM, John Levine wrote:
>> According to BGB <cr88192@gmail.com>:
>>> Well, that and it answers another mystery: "How could you have fit
>>> Unix onto computers with only a few K of RAM?..." Apparently, they
>>> didn't, they (somehow) had access to machines in the 70s with MB of
>>> RAM.
>>
>> Yes, we did. The most memory you could put on a PDP-11/45 was 248K,
>> the 256K bus address space minus 8K for the I/O devices.
>
>
> Curious then...

The source to UNIX v7 is available, you could build it for your CPU.

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<ipwcK.187447$Kdf.150611@fx96.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25053&group=comp.arch#25053

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx96.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
References: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me> <t4s5b4$15n4$2@gal.iecc.com> <t4tei5$sli$1@dont-email.me>
In-Reply-To: <t4tei5$sli$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 78
Message-ID: <ipwcK.187447$Kdf.150611@fx96.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Wed, 04 May 2022 14:50:54 UTC
Date: Wed, 04 May 2022 10:49:32 -0400
X-Received-Bytes: 4071
 by: EricP - Wed, 4 May 2022 14:49 UTC

BGB wrote:
> On 5/3/2022 4:03 PM, John Levine wrote:
>> According to BGB <cr88192@gmail.com>:
>>> Well, that and it answers another mystery: "How could you have fit Unix
>>> onto computers with only a few K of RAM?..." Apparently, they didn't,
>>> they (somehow) had access to machines in the 70s with MB of RAM.
>>
>> Yes, we did. The most memory you could put on a PDP-11/45 was 248K,
>> the 256K bus address space minus 8K for the I/O devices.
>
>
> Curious then...
>
>
> I am also going to guess that the 16K x 1b or 64K x 1b DIP16 RAM chips
> weren't a thing yet...
>
> Best I can tell is that they caught on "some time in the 70s" (replacing
> magnetic core memory which had in-turn replaced drum-memory and
> william's-tube memory).

According to Wikipedia, the 11/45 was introduced in 1972 and
could have 256 kB of semiconductor memory.

A chip of that day was the Intel 1103 1kb*1 DRAM in an 18 pin DIP,
takes say 0.5 sq" (inch) of board space, plus 0.5 sq" for wires.
So 8 sq" per kB of circuit board space.

256 kB = 2048 sq" = ~14 sq ft of memory boards.
Say a board is 24" * 24" = 4 sq ft.

So 3.5 large memory boards for 256 kB of 1 kb 1103 DRAMs. Quite doable.

> Haven't actually seen any 70s era PCBs first hand, so not really sure
> how to gauge this by looking at it.
>
> Checking Google Images, I guess the pattern is that apparently a lot of
> the traces are more haphazard and wavy. Almost more like a drawing of a
> circuit, than the more "straight lines and 45 degree angles" seen on
> most other (slightly newer) PCBs.

PCB's were done by hand, colored tape on mylar.
TTL is ~25 MHz max so rules to line layouts are much simpler,
just worry about reflections at the end of buses,
and even those you could get away without terminating.

> Well, and also the examples seen seemed to have more discrete components
> relative to the number of ICs, and typically more sparsely populated (as
> opposed to a larger number of DIP packages packed closely together).

Almost all PCB's were 1 or 2 sided and that means you have
to leave space around the chips for running wires.
And remember, gates pretty much came individually wrapped
to lock in freshness and flavor

Multi-layer PCB's were possible but only the likes
of IBM could afford them (IIRC IBM had 6 layers but
I don't know if that includes 2 ground plane layers.)

> Well, excluding things like surface-mount QFPs and similar, which
> immediately give something away as 90s or newer (with 80s and older
> being pretty much exclusively DIP chips and other through-hole
> components and similar).
>
>
> Not entirely sure when the thing of using a "bare die mounted to a board
> under a big blob of black epoxy" thing came around.

If you mount a chip like that you can't unsolder it.
Those individual chips are expensive and you don't
want to throw out a whole board if one is bad.
You have to be sure of your supplier quality
and have a large volume of boards being produced.

Now days people cost $250/hr and the board costs, well,
a Raspberry Pi Pico costs $4. So you throw out the computer.

Re: Fortran archaeology, Upcoming DFP support in clang/LLVM

<c9888726-8ab7-4cd8-8765-204f9ce140c2n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25054&group=comp.arch#25054

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1301:b0:2f3:af1d:aa57 with SMTP id v1-20020a05622a130100b002f3af1daa57mr7171732qtk.257.1651680674385;
Wed, 04 May 2022 09:11:14 -0700 (PDT)
X-Received: by 2002:a05:6870:b383:b0:e9:2fea:2148 with SMTP id
w3-20020a056870b38300b000e92fea2148mr85333oap.103.1651680674157; Wed, 04 May
2022 09:11:14 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 4 May 2022 09:11:13 -0700 (PDT)
In-Reply-To: <t4t3dg$bi3$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:84e4:a582:fd62:9c5f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:84e4:a582:fd62:9c5f
References: <t4peor$cch$1@dont-email.me> <12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com>
<t4s130$p3o$1@newsreader4.netcologne.de> <67754cbf-fcbf-4ce2-887d-6c6b55087427n@googlegroups.com>
<t4s4mn$15n4$1@gal.iecc.com> <75b1ae32-3f22-4c67-8441-03e825eb710fn@googlegroups.com>
<t4t3dg$bi3$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c9888726-8ab7-4cd8-8765-204f9ce140c2n@googlegroups.com>
Subject: Re: Fortran archaeology, Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 04 May 2022 16:11:14 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 28
 by: MitchAlsup - Wed, 4 May 2022 16:11 UTC

On Wednesday, May 4, 2022 at 12:36:52 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Tuesday, May 3, 2022 at 3:52:43 PM UTC-5, John Levine wrote:
> >> According to MitchAlsup <Mitch...@aol.com>:
> >> >On Tuesday, May 3, 2022 at 2:50:59 PM UTC-5, Thomas Koenig wrote:
> >> >> MitchAlsup <Mitch...@aol.com> schrieb:
> >> >> > in 1982 I was on a project that built a FORTRAN runtime library. We built
> >> >> > the WRITE routines so you only pulled in the data formatters you actually
> >> >> > used, not the entire suite of potentials.
> >> >> How did you deal with formats created at run-time?
> >> ><
> >> >The FORTRAN of that era did not have those.
> >> Sure it did. Fortran 77 let you put your format statement in a character variable.
> ><
> > Yes, but you could not invent a random-precision floating point type in a character string.
> > You were restricted to the format types already installed.
> Sure. FORTRAN 77 did not have derived types, these were introduced
> in Fortran 90, and derived type I/O was only added in Fortran 2003
> (and its specification is a mess even now).
>
> But if you didn't know in advance which of the pre-selected formats
> would be used, how did you decide which ones to pull in? Or did
> you go by type of the I/O variable, hoping that nobody would
> ever print a real as an integer?
<
Just like any dynamically linked library (hierarchy). You dynamically load
each format subroutine as it gets called--that is all the calls were part
of the object module but all of the called subroutines were dynamically
linked individually.

Re: Upcoming DFP support in clang/LLVM

<t4u9s4$v3i$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25055&group=comp.arch#25055

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 16:33:08 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4u9s4$v3i$1@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
Injection-Date: Wed, 4 May 2022 16:33:08 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:f207:0:7285:c2ff:fe6c:992d";
logging-data="31858"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Wed, 4 May 2022 16:33 UTC

BGB <cr88192@gmail.com> schrieb:
> On 5/3/2022 4:34 AM, Thomas Koenig wrote:
>> BGB <cr88192@gmail.com> schrieb:

>> The PDP-11 they started serious UNIX development on had 24 kB of
>> memory and a half-megabyte disk.
>>
>> Source: UNIX: A History and a Memoir, Brian Kernighan, page 52.
>
> OK, this turns it back into being a mystery how it could fit...

These guys were really good, and they made a _lot_ of the limited
resources that they had.

The lack of resources was a prime reason why UNIX was so lean -
they had no room for unnecessary features. Ken Thompson makes
mention of that in his Turing Award acceptance speech - if they
had had a PDP-10 to play with, UNIX would never have been as
successful.

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<0001HW.2822ED9A01420C5670000B66838F@news.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25056&group=comp.arch#25056

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: findlayb...@blueyonder.co.uk (Bill Findlay)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 04 May 2022 18:21:30 +0100
Organization: none
Lines: 18
Message-ID: <0001HW.2822ED9A01420C5670000B66838F@news.individual.net>
References: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me> <t4s5b4$15n4$2@gal.iecc.com> <t4tei5$sli$1@dont-email.me> <ipwcK.187447$Kdf.150611@fx96.iad>
Reply-To: findlaybill@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net lSoTR/OPZcRiCKXWROe40AcefNo145lE+RPaH9SbayVkb7YwwE
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:OEvl2yGv9rYjQ0M1+1ggj23je7o=
User-Agent: Hogwasher/5.24
 by: Bill Findlay - Wed, 4 May 2022 17:21 UTC

On 4 May 2022, EricP wrote
(in article <ipwcK.187447$Kdf.150611@fx96.iad>):

> According to Wikipedia, the 11/45 was introduced in 1972 and
> could have 256 kB of semiconductor memory.

Then wikipedia is almost right.
The 11/45 could have up to 128KW of memory, most of which had to be core.
11/45 RAM, either ~450ns MOS or ~300ns bipolar, was limited to 32KW.

We had 32KW of MOS which we put at the low end of the physical address space,
to get a consistent advantage from its higher speed when running in the
kernel.
It ran hotter than core, so that might have been an issue limiting its size.
--
Bill Findlay

Re: Upcoming DFP support in clang/LLVM

<t4ud8v$1f3$2@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25057&group=comp.arch#25057

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 17:31:11 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4ud8v$1f3$2@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com>
<t4s130$p3o$1@newsreader4.netcologne.de>
<67754cbf-fcbf-4ce2-887d-6c6b55087427n@googlegroups.com>
Injection-Date: Wed, 4 May 2022 17:31:11 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:f207:0:7285:c2ff:fe6c:992d";
logging-data="1507"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Wed, 4 May 2022 17:31 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Tuesday, May 3, 2022 at 2:50:59 PM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:

>> > Computers are more flexible today, why can't we just pull in the ones
>> > being used and not every-friggen-thing ?
><
>> Shared libraries. You can see how well they work from the
>> proliferation of dockers, snaps, and whatnot.
><
> Abuse of the concept of shared libraries is more like it.

They're far too often at the version that causes grief,
which is why snaps were invented.

Never mind that you should not even have a shared library if it
is only used by a single executable. All it does then is add
overhead.

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4ujd2$1bk8$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25058&group=comp.arch#25058

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 19:15:46 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4ujd2$1bk8$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me> <ipwcK.187447$Kdf.150611@fx96.iad> <0001HW.2822ED9A01420C5670000B66838F@news.individual.net>
Injection-Date: Wed, 4 May 2022 19:15:46 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="44680"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me> <ipwcK.187447$Kdf.150611@fx96.iad> <0001HW.2822ED9A01420C5670000B66838F@news.individual.net>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Wed, 4 May 2022 19:15 UTC

According to Bill Findlay <findlaybill@blueyonder.co.uk>:
>On 4 May 2022, EricP wrote
>(in article <ipwcK.187447$Kdf.150611@fx96.iad>):
>
>> According to Wikipedia, the 11/45 was introduced in 1972 and
>> could have 256 kB of semiconductor memory.
>
>Then wikipedia is almost right.
>The 11/45 could have up to 128KW of memory, most of which had to be core.
>11/45 RAM, either ~450ns MOS or ~300ns bipolar, was limited to 32KW.

Our machine at Yale had core but we also had a third party add-in cache
card which sped it up considerably.

The 11/70 was an 11/45 with a built in cache and a new memory bus that allowed 4MB of RAM.
--
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

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4ujvf$jfl$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25060&group=comp.arch#25060

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 14:25:24 -0500
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <t4ujvf$jfl$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4s5b4$15n4$2@gal.iecc.com> <t4tei5$sli$1@dont-email.me>
<ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 4 May 2022 19:25:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b2af24ad729b5d3bd45a693eb74ba0e5";
logging-data="19957"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XdFwLWV4HVoo+coBiw11w"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:3U3hXG3cpR5hbClffouLuvyG7a4=
In-Reply-To: <ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com>
Content-Language: en-US
 by: BGB - Wed, 4 May 2022 19:25 UTC

On 5/4/2022 4:32 AM, aph@littlepinkcloud.invalid wrote:
> BGB <cr88192@gmail.com> wrote:
>> On 5/3/2022 4:03 PM, John Levine wrote:
>>> According to BGB <cr88192@gmail.com>:
>>>> Well, that and it answers another mystery: "How could you have fit Unix
>>>> onto computers with only a few K of RAM?..." Apparently, they didn't,
>>>> they (somehow) had access to machines in the 70s with MB of RAM.
>>>
>>> Yes, we did. The most memory you could put on a PDP-11/45 was 248K,
>>> the 256K bus address space minus 8K for the I/O devices.
>>
>> Curious then...
>
> It's not that mysterious. The source code for UNIX 6th Edition is
> available here https://warsus.github.io/lions-/
>

Looks some, yeah, this stuff is a bit more minimal than I have been
tending to be doing in TestKern and similar.

I guess, in this sense, it probably makes a little more sense how they
fit stuff into less space.

Also apparently Unix v6 "swapped" programs by writing out and reloading
their entire memory space (vs paged virtual memory or similar).

I am a bit confused to how it works. I am guessing here that the
"kernel" was not a separate entity which was called into by programs,
but rather existed within each program (so, it was more like a series of
programs daisy-chained together, rather than "the kernel" sitting around
externally and supervising all of the running processes?).

....

This would be unlike (even) MS-DOS, where the kernel remained resident
(as its own entity) when programs were loaded, and was called into via
interrupts.

Also back at my own code, noting the 2.5k lines for the Boot ROM's FAT
driver, and thinks, "yeah, maybe this could be a little more minimal".
Add ~ 1.3k lines for the PE/COFF loader, ...

Though, the version within TestKern itself if 3.8k lines (plus another
2k lines for the VFS and glue code, ...).

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4uod9$1vaj$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25063&group=comp.arch#25063

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 20:41:13 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4uod9$1vaj$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me> <ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me>
Injection-Date: Wed, 4 May 2022 20:41:13 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="64851"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me> <ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Wed, 4 May 2022 20:41 UTC

According to BGB <cr88192@gmail.com>:
>Also apparently Unix v6 "swapped" programs by writing out and reloading
>their entire memory space (vs paged virtual memory or similar).

Right. The PDP-11's didn't have paging, just a much cruder scheme that
mapped the 64K address space as eight 8K chunks, which was much too
big to treat as pages. At the time swapping was quite common. CTSS did
it as did the PDP-6/10 operating systems and the ones for the GE 635.

The only paged systems at the time I can think of are Multics on GE,
TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
think you could buy one of those.

>I am a bit confused to how it works. I am guessing here that the
>"kernel" was not a separate entity which was called into by programs,
>but rather existed within each program ...

Nope. The -11 had separately mapped kernel and user address spaces.
The kernel ran in the kernel space in low memory, the user ran in the
user space. The kernel space never changed except maybe for one chunk
used to look at high memory.

(so, it was more like a series of
>programs daisy-chained together, rather than "the kernel" sitting around
>externally and supervising all of the running processes?).

Nope. The kernel supervised all of the running processes.

>Also back at my own code, noting the 2.5k lines for the Boot ROM's FAT
>driver, and thinks, "yeah, maybe this could be a little more minimal".
>Add ~ 1.3k lines for the PE/COFF loader, ...

Holy bloatware. I don't think the linker or assembler was 1300 lines.

--
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

Re: Upcoming DFP support in clang/LLVM

<t4uqd7$nul$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25064&group=comp.arch#25064

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 16:15:08 -0500
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <t4uqd7$nul$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<4dc25465-51ff-45c5-b369-54fb38a27653n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 4 May 2022 21:15:19 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b2af24ad729b5d3bd45a693eb74ba0e5";
logging-data="24533"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+bpdO8GIx+giX9WMHNlPB"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:LY2k9mcDBO6IOaH9h/kkGW2/LOw=
In-Reply-To: <4dc25465-51ff-45c5-b369-54fb38a27653n@googlegroups.com>
Content-Language: en-US
 by: BGB - Wed, 4 May 2022 21:15 UTC

On 5/3/2022 4:36 AM, Michael S wrote:
> On Monday, May 2, 2022 at 11:26:06 PM UTC+3, Ivan Godard wrote:
>> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>
> What about quad-precision binary floating point?

More viable than DFP at least...

I can at least imagine how one could do it within a plausible cost range
in hardware. It would mostly just be slower and more expensive than
Binary64.

Same issue as my Binary96 format (truncated Binary128), just more so.

I mostly left this stuff to software for now, as both "long double" and
"__float128" (same format in my case, but differing mostly in the "long
double" operators don't need full precision).

At this point, it is possible that Float128 emulation could probably be
faster with a "MULHU.X" instruction (128 * 128 => High 128).

I was tempted initially (when implementing the 64-bit MUL/DIV) to go
with 128-bit rather than 64-bit, but this would have increased cost and
made it twice as slow (~ 130 cycles to do a multiply). So, didn't do so.

Also seemingly it being more cost effective to try to make integer math
fast enough to emulate it effectively, than to support it in hardware
(and have it hardly ever be used).

At least these 128-bit integer operations manage to still be useful
occasionally in other contexts.

For printf, I ended up using a 'j' modifier for now, eg:
__int128 xi;
xi=...;
printf("%032jX\n", xi);

Technically 'j' means 'intmax_t', but I ended up going for 128-bit
intmax, so it works.

Potentially also redefine 'L' when used with an integer type as this:
"%Lf" //long double / __float128
"%Ld" //__int128

There is also:
"%I64X", __int64 (long / long long)
"%I128X", __int128

Things like _BitInt allow for larger numbers, but they don't really
count (and don't yet have printf support in cases where values are over
128 bits).

Could probably just use Ixxx noration for this though:
"%I384X" //384-bit integer

....

> Right now, it seems that on x64 Linux __float128 is supported by compiler. However I was unable to
> figure out whether run-time support library is provided by LLVM or compiler relies on system-supplied
> RTL for actual work. Also, clang does not appear to supply <quadmath.h> header of its own.
>
> On x64 Windows (MSYS2) situation is much worse - clang compiler pretends to support __float128, but
> does not understand the ABI.
>
> On aarch64 Linux, it seems there is no support at all, neither as __float128 nor as _Float128.
> I'd dare to say that it's a little better than x64 Window (at least, not misleading), but hardly satisfactory.
>
> POWER64LE - the same as aarch64.
>
> RISC V (both 32 bits and 64 bits) - the same as aarch64.
>
> Above I intentionally listed only those targets on which gcc support either __float128 or _Float128 or both.
>
>

I guess maybe it isn't really "in demand" enough to make a strong case
for "make it work".

Didn't realize the situation was that bad, but hadn't had that much
reason to test it.

For most tasks, Binary64 is plenty sufficient.

In cases where I need __int128 or __float128 on Windows, I generally end
up using software implementations (implemented via structs), mostly as
MSVC doesn't support these either.

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<0001HW.282332DC015247D270000B66838F@news.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25065&group=comp.arch#25065

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: findlayb...@blueyonder.co.uk (Bill Findlay)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 04 May 2022 23:17:00 +0100
Organization: none
Lines: 17
Message-ID: <0001HW.282332DC015247D270000B66838F@news.individual.net>
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me> <ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com>
Reply-To: findlaybill@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net xtWaDcSru8ncd8hgIIUk7wg0Yq/stRfHoO5+cJWx+BwR+R/K/V
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:dRPTou0NJm10RBYaq5jbSVl1Dq0=
User-Agent: Hogwasher/5.24
 by: Bill Findlay - Wed, 4 May 2022 22:17 UTC

On 4 May 2022, John Levine wrote
(in article <t4uod9$1vaj$1@gal.iecc.com>):

> The only paged systems at the time I can think of are Multics on GE,
> TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
> nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
> think you could buy one of those.

If by "the time", you mean 1972, when the 11/45 went on sale,
ICL's System 4/75, and the 1900 models 4A and 6A had been paging for years.
By the time of Unix V5 the entire 2900 Series had paging and segmentation,
and there were many paging systems from other manufacturers.

--
Bill Findlay

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4uvgq$fej$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25066&group=comp.arch#25066

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 17:42:24 -0500
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <t4uvgq$fej$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me>
<ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me>
<t4uod9$1vaj$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 4 May 2022 22:42:34 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="91f2b55ce3b3229e84e8dd395e96bfa6";
logging-data="15827"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/sDAwRLmOxx9cfClQcRKwm"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:Wa8bKpgFXJ1Z2pHCvmaT4XR6zZQ=
In-Reply-To: <t4uod9$1vaj$1@gal.iecc.com>
Content-Language: en-US
 by: BGB - Wed, 4 May 2022 22:42 UTC

On 5/4/2022 3:41 PM, John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>> Also apparently Unix v6 "swapped" programs by writing out and reloading
>> their entire memory space (vs paged virtual memory or similar).
>
> Right. The PDP-11's didn't have paging, just a much cruder scheme that
> mapped the 64K address space as eight 8K chunks, which was much too
> big to treat as pages. At the time swapping was quite common. CTSS did
> it as did the PDP-6/10 operating systems and the ones for the GE 635.
>
> The only paged systems at the time I can think of are Multics on GE,
> TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
> nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
> think you could buy one of those.
>

OK.

I wasn't sure.
I know that both 32-bit x86, and ARM, had this.
M68K apparently had it as soft of a chipset feature (until it was
integrated with the CPU).

Also SH4 had a software managed TLB, and the BJX2 TLB design is still
partially derived from the SH4.

>> I am a bit confused to how it works. I am guessing here that the
>> "kernel" was not a separate entity which was called into by programs,
>> but rather existed within each program ...
>
> Nope. The -11 had separately mapped kernel and user address spaces.
> The kernel ran in the kernel space in low memory, the user ran in the
> user space. The kernel space never changed except maybe for one chunk
> used to look at high memory.
>
> (so, it was more like a series of
>> programs daisy-chained together, rather than "the kernel" sitting around
>> externally and supervising all of the running processes?).
>
> Nope. The kernel supervised all of the running processes.
>

OK, this makes sense.

Quick skim wasn't making much sense over what I was looking at.

>> Also back at my own code, noting the 2.5k lines for the Boot ROM's FAT
>> driver, and thinks, "yeah, maybe this could be a little more minimal".
>> Add ~ 1.3k lines for the PE/COFF loader, ...
>
> Holy bloatware. I don't think the linker or assembler was 1300 lines.
>

Yeah, the PE loader contains several sub-parts:
LZ4 and RP2 decoders;
Code to apply base relocations;
Code to calculate the checksum;
Code to read the PE headers, and then do the loading/decompression.
The LZ decode being directly integrated with the PE loading process.

The loader calculates and verifies the image checksum for
error-detection purposes. I replaced the original PE/COFF checksum
algorithm (effectively a linear sum) with a modified algorithm which was
more likely to detect the sorts of damage done by a misbehaving LZ
decoder (namely a two-level sum, with the final sums XOR'ed together).

The two-level sum could give some similar properties to an Adler32
checksum, while also being significantly faster.

Note that something like Deflate would have added significantly more
bulk to the loader (and would only reduce binary sizes by around 7% over
LZ4).

Since the loader is primarily IO bound, an uncompressed PE/COFF would
take around 3 times longer to load.

The LZ is integrated with the PE format mostly as this avoids needing to
first decompress into a temporary buffer and then copy out the sections
to their final locations (this would have been the main alternative
strategy).

The Boot ROM also contains an ELF loader and similar as well.

The base reloc part is useful if one wants to ASLR the kernel (currently
disabled because it makes debugging harder; but would be better for
security).

I originally copy/pasted the boot loader's FAT code from the emulator,
as opposed to writing something minimal for the task. It still includes
a lot of functionality that is not really necessary for booting the
kernel (it being more or less a full filesystem driver, with a few
things disabled).

Similar code is also used in the TestKern "OS", basically:
FAT12/FAT16/FAT32;
Support for VFAT LFN's;
Support for a hack for faking symlinks and similar on FAT.

The encoding for VFAT LFN's is kinda ugly and awkward, basically
involving UCS-2 / UTF-16. Contrast with the 8.3 names which
(conventionally) assume Codepage 1252 (both cases being transformed
to/from UTF-8 for the main VFS layer).

But, yeah, these things eat up a fair chunk of the 32K Boot ROM.

While arguably, NTFS could be a "better" filesystem in some ways, its
added complexity vs FAT is a bit extreme.

Sadly, there are relatively few alternatives (eg: Windows can't access
EXTn filesystems).

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<3fa85bab-33f6-4933-87b0-d0486e11e807n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25067&group=comp.arch#25067

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5b51:0:b0:2f3:8654:53b2 with SMTP id n17-20020ac85b51000000b002f3865453b2mr21571404qtw.300.1651705673262;
Wed, 04 May 2022 16:07:53 -0700 (PDT)
X-Received: by 2002:a05:6870:478f:b0:e9:8c5c:3c37 with SMTP id
c15-20020a056870478f00b000e98c5c3c37mr918309oaq.217.1651705673027; Wed, 04
May 2022 16:07:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 4 May 2022 16:07:52 -0700 (PDT)
In-Reply-To: <t4uod9$1vaj$1@gal.iecc.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:84e4:a582:fd62:9c5f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:84e4:a582:fd62:9c5f
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me>
<ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3fa85bab-33f6-4933-87b0-d0486e11e807n@googlegroups.com>
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 04 May 2022 23:07:53 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 47
 by: MitchAlsup - Wed, 4 May 2022 23:07 UTC

On Wednesday, May 4, 2022 at 3:41:18 PM UTC-5, John Levine wrote:
> According to BGB <cr8...@gmail.com>:
> >Also apparently Unix v6 "swapped" programs by writing out and reloading
> >their entire memory space (vs paged virtual memory or similar).
> Right. The PDP-11's didn't have paging, just a much cruder scheme that
> mapped the 64K address space as eight 8K chunks, which was much too
> big to treat as pages. At the time swapping was quite common. CTSS did
> it as did the PDP-6/10 operating systems and the ones for the GE 635.
>
> The only paged systems at the time I can think of are Multics on GE,
> TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
> nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
> think you could buy one of those.
> >I am a bit confused to how it works. I am guessing here that the
> >"kernel" was not a separate entity which was called into by programs,
> >but rather existed within each program ...
>
> Nope. The -11 had separately mapped kernel and user address spaces.
<
PDP-11/20 did not have separate code/data. /40, /45, and /75 did;
don't remember about the /10 and /05.
<
> The kernel ran in the kernel space in low memory, the user ran in the
> user space. The kernel space never changed except maybe for one chunk
> used to look at high memory.
<
> (so, it was more like a series of
> >programs daisy-chained together, rather than "the kernel" sitting around
> >externally and supervising all of the running processes?).
<
> Nope. The kernel supervised all of the running processes.
<
RSTS allowed user programs to perform their own I/O (via UniBus access).
<
> >Also back at my own code, noting the 2.5k lines for the Boot ROM's FAT
> >driver, and thinks, "yeah, maybe this could be a little more minimal".
> >Add ~ 1.3k lines for the PE/COFF loader, ...
<
> Holy bloatware. I don't think the linker or assembler was 1300 lines.
<
I got an entire BASIC interpreter in less than 16KB including asynchronous
I/O {including all the math, transcendentals, networking, back-end mainframe
access, and some decimal extensions.} 8080 Assembly.
<
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4v7to$ttu$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25069&group=comp.arch#25069

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Wed, 4 May 2022 18:06:01 -0700
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <t4v7to$ttu$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me>
<ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me>
<t4uod9$1vaj$1@gal.iecc.com>
<0001HW.282332DC015247D270000B66838F@news.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 5 May 2022 01:06:00 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="916e63287c3dd9ba57b55e3f72762223";
logging-data="30654"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ntnR0kxp72bQYm9Gum2lR"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Cancel-Lock: sha1:QZbWlSpyoj2WEKaBDShW9S3bXxI=
In-Reply-To: <0001HW.282332DC015247D270000B66838F@news.individual.net>
Content-Language: en-US
 by: Ivan Godard - Thu, 5 May 2022 01:06 UTC

On 5/4/2022 3:17 PM, Bill Findlay wrote:
> On 4 May 2022, John Levine wrote
> (in article <t4uod9$1vaj$1@gal.iecc.com>):
>
>> The only paged systems at the time I can think of are Multics on GE,
>> TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
>> nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
>> think you could buy one of those.
>
> If by "the time", you mean 1972, when the 11/45 went on sale,
> ICL's System 4/75, and the 1900 models 4A and 6A had been paging for years.
> By the time of Unix V5 the entire 2900 Series had paging and segmentation,
> and there were many paging systems from other manufacturers.
>

Hardware segs were on the B5000 circa 1961

Re: tiny little pages, was Upcoming DFP support in clang/LLVM

<t4vb1d$11um$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25070&group=comp.arch#25070

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: tiny little pages, was Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 01:59:09 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4vb1d$11um$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com> <0001HW.282332DC015247D270000B66838F@news.individual.net> <t4v7to$ttu$1@dont-email.me>
Injection-Date: Thu, 5 May 2022 01:59:09 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="34774"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com> <0001HW.282332DC015247D270000B66838F@news.individual.net> <t4v7to$ttu$1@dont-email.me>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Thu, 5 May 2022 01:59 UTC

According to Ivan Godard <ivan@millcomputing.com>:
>On 5/4/2022 3:17 PM, Bill Findlay wrote:
>> On 4 May 2022, John Levine wrote
>> (in article <t4uod9$1vaj$1@gal.iecc.com>):
>>
>>> The only paged systems at the time I can think of are Multics on GE,
>>> TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
>>> nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
>>> think you could buy one of those.
>>
>> If by "the time", you mean 1972, when the 11/45 went on sale,
>> ICL's System 4/75, and the 1900 models 4A and 6A had been paging for years.
>> By the time of Unix V5 the entire 2900 Series had paging and segmentation,
>> and there were many paging systems from other manufacturers.
>>
>
>Hardware segs were on the B5000 circa 1961

Sure, but each segment was swapped as a unit, not paged.

--
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

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4vbgq$11um$2@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25071&group=comp.arch#25071

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 02:07:22 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4vbgq$11um$2@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com> <3fa85bab-33f6-4933-87b0-d0486e11e807n@googlegroups.com>
Injection-Date: Thu, 5 May 2022 02:07:22 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="34774"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com> <3fa85bab-33f6-4933-87b0-d0486e11e807n@googlegroups.com>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Thu, 5 May 2022 02:07 UTC

According to MitchAlsup <MitchAlsup@aol.com>:
>> Nope. The -11 had separately mapped kernel and user address spaces.
><
>PDP-11/20 did not have separate code/data. /40, /45, and /75 did;
>don't remember about the /10 and /05.

The /10 and /05, which were the same machine, were a lower cost
reimplementation of a /20 and had as far as I recall the same
instruction set as the /20. The terminal emulator for our early bitmap
terminals ran on a /10.

>> Nope. The kernel supervised all of the running processes.
><
>RSTS allowed user programs to perform their own I/O (via UniBus access).

Unix never did that, didn't see the need. Since everyone had all the
source code and the device driver API was quite simple, if you needed
to use a new device, you could write a kernel driver for it.

The /45 actually had three modes: kernel, supervisor, and user. There was
both a current mode and a "previous" mode, with instructions to move a word
to or from the previous data space, which is how the kernel put stuff in and
out of user address space.

Unix didn't use supervisor, so my hack to let user programs access the
graphics memory was to set the supervisor memory map to point to your
terminal's memory, then adjust some mode bits so that the previous
mode in user programs was supervisor, so the move to/from previous
instructions directly read and wrote your screen memory, no system
calls or context switches needed. It was a hack but it worked great.

--
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

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<qBGcK.27703$aLT.19910@fx05.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25072&group=comp.arch#25072

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
References: <t4peor$cch$1@dont-email.me> <t4tei5$sli$1@dont-email.me> <ZoOdnabqD9KB1e__nZ2dnUU7-UHNnZ2d@supernews.com> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com>
In-Reply-To: <t4uod9$1vaj$1@gal.iecc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 49
Message-ID: <qBGcK.27703$aLT.19910@fx05.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Thu, 05 May 2022 02:26:30 UTC
Date: Wed, 04 May 2022 22:26:17 -0400
X-Received-Bytes: 3063
 by: EricP - Thu, 5 May 2022 02:26 UTC

John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>> Also apparently Unix v6 "swapped" programs by writing out and reloading
>> their entire memory space (vs paged virtual memory or similar).
>
> Right. The PDP-11's didn't have paging, just a much cruder scheme that
> mapped the 64K address space as eight 8K chunks, which was much too
> big to treat as pages. At the time swapping was quite common. CTSS did
> it as did the PDP-6/10 operating systems and the ones for the GE 635.
>
> The only paged systems at the time I can think of are Multics on GE,
> TSS and CP/67 on IBM (maybe also MTS), and Tenex on PDP-10 with
> nonstandard paging hardware. Oh, and the Atlas in the UK but I don't
> think you could buy one of those.

I vaguely recall reading about PDP-11 OS, RSX I think,
used thunking for a semiautomatic segment swapping.

>> I am a bit confused to how it works. I am guessing here that the
>> "kernel" was not a separate entity which was called into by programs,
>> but rather existed within each program ...
>
> Nope. The -11 had separately mapped kernel and user address spaces.
> The kernel ran in the kernel space in low memory, the user ran in the
> user space. The kernel space never changed except maybe for one chunk
> used to look at high memory.

IIUC you manually arrange the subroutines into 8 kB segments
and then the linker and run-time would use thunks to
check if the proper segment for each routine was loaded,
load it if not, and branch to the routine.

It is still limited to 64 kB at once (or 64 kB instruction
and 64 kB data space depending on MMU model).

But if a segment was already loaded in physical space then
a smart OS might know this and just write 1 mapping register
to map that segment.
And maybe user mode could set a flag so all further thunks
to the same segment wouldn't even need to call the OS.
So potentially could be pretty efficient.

> (so, it was more like a series of
>> programs daisy-chained together, rather than "the kernel" sitting around
>> externally and supervising all of the running processes?).
>
> Nope. The kernel supervised all of the running processes.

Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4vi1l$1m7b$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25073&group=comp.arch#25073

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 03:58:45 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4vi1l$1m7b$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com> <qBGcK.27703$aLT.19910@fx05.iad>
Injection-Date: Thu, 5 May 2022 03:58:45 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="55531"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <t4ujvf$jfl$1@dont-email.me> <t4uod9$1vaj$1@gal.iecc.com> <qBGcK.27703$aLT.19910@fx05.iad>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Thu, 5 May 2022 03:58 UTC

According to EricP <ThatWouldBeTelling@thevillage.com>:
>I vaguely recall reading about PDP-11 OS, RSX I think,
>used thunking for a semiautomatic segment swapping. ...

>IIUC you manually arrange the subroutines into 8 kB segments
>and then the linker and run-time would use thunks to
>check if the proper segment for each routine was loaded,
>load it if not, and branch to the routine.
>
>It is still limited to 64 kB at once (or 64 kB instruction
>and 64 kB data space depending on MMU model).
>
>But if a segment was already loaded in physical space then
>a smart OS might know this and just write 1 mapping register
>to map that segment.
>And maybe user mode could set a flag so all further thunks
>to the same segment wouldn't even need to call the OS.
>So potentially could be pretty efficient.

I can see how that might sort of work, but urrgh.

Since Unix processes are pretty cheap, you could use a bunch of
processes to get the effect of a bigger program, e.g., the C compiler
was three passes plus the assembler, with each pass being pretty
small. My recollection is that we didn't run into the size limits very
often.

--
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

Re: Upcoming DFP support in clang/LLVM

<t50cpf$1tnk$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25081&group=comp.arch#25081

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 13:35:11 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t50cpf$1tnk$1@gioia.aioe.org>
References: <t4qm5s$8rv$1@dont-email.me>
<memo.20220503192241.8344H@jgd.cix.co.uk> <t4s699$ra2$1@dont-email.me>
<9c5f44df-efca-4fb3-845e-b37589b7097fn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="63220"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Thu, 5 May 2022 11:35 UTC

MitchAlsup wrote:
> On Tuesday, May 3, 2022 at 4:19:40 PM UTC-5, BGB wrote:
>> On 5/3/2022 1:21 PM, John Dallman wrote:
>>> In article <t4qm5s$8rv$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
>>>
>>>> This is mostly at-odds with the "everything and the kitchen sink"
>>>> approach common in C++ land, where people are chasing after the
>>>> newest language features is some attempt to be "modern".
>>>
>>> My employers have various teams that get bees in their bonnets about C++
>>> features, though some teams definitely do this more than others. There's
>>> enough code shared between different products that it's worth
>>> coordinating company-wide.
>>>
>>> My conclusion has been that you need to stay about one version of the C++
>>> standard behind the bleeding age, given that it takes a while for the
>>> standards to get implemented, and then there are product release cycles
>>> to accommodate.
>>>
>> I don't get the point personally.
>>
>> Almost better I think to stick with the minimal feature set needed to
>> accomplish a given task (being conservative about what is used and when).
> <
> When forced to use C++, I use the C subset.

As I've stated before I tend to use C(+), where all the (+) features
have typically been included in more recent updates to the C standard.

> And I still use printf() instead of <<.

Ditto. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Upcoming DFP support in clang/LLVM

<t50dgl$go5$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25082&group=comp.arch#25082

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 13:47:32 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t50dgl$go5$1@gioia.aioe.org>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<t4sgn4$19f$1@dont-email.me> <t4spai$n08$1@dont-email.me>
<da4dbb00-45c0-4731-8630-cd10aba9151fn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="17157"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Thu, 5 May 2022 11:47 UTC

Quadibloc wrote:
> On Tuesday, May 3, 2022 at 8:44:37 PM UTC-6, BGB wrote:
>
>> And, a world where everyday people could interact with electronics
>> devices and similar directly, rather than, say, read a book or something.
>
> Ordinary people did interact with electronic devices personally.
>
> Even in the 1920s, whenever they turned on the radio, because it used
> vacuum tubes to amplify the signal.
>
> What most people didn't do personally in the 1960s, though, was interact
> directly with electronic digital computers directly. Those they read about
> in books.
>
> This would have started to change when the first pocket calculators
> came out. 1972 was the year when the HP 35, a scientific pocket
> calculator, startled the world... a few years later, they became cheap
> enough for anyone to afford - by 1976, or perhaps earlier.

I bought my very first calculator in high school, it had just dropped
40% in price, to NOK 565,- from over 1K. (This was the SR-50A version of
the SR-50 which originally cost $170 in 1974). In today's money that is
about $400, so a significant expense that I had to save up for over some
months.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Upcoming DFP support in clang/LLVM

<t50dni$jvb$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25083&group=comp.arch#25083

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 13:51:14 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t50dni$jvb$1@gioia.aioe.org>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<t4sgn4$19f$1@dont-email.me> <t4spai$n08$1@dont-email.me>
<b24676b2-b8a9-4dfb-9cf9-18a15b362858n@googlegroups.com>
<t4t3ho$bi3$2@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="20459"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Thu, 5 May 2022 11:51 UTC

Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> On Tuesday, May 3, 2022 at 8:44:37 PM UTC-6, BGB wrote:
>>
>>> Reads some, I guess the great drawback of color back then was that it
>>> ate up around 2x to 3x as much film stock as black-and-white.
>>>
>>>
>>> Seems like a cheaper compromise could have been to have a spinning color
>>> filter wheel and then record frames in alternating colors, say:
>>> Yellow, Cyan, Yellow, Magenta
>>> Or:
>>> Green, Blue, Green, Red
>>>
>>> Former would have less flicker, but less saturation.
>>> Latter would have more flicker, but better saturation.
>>>
>>> Or, maybe:
>>> Yellow, Blue, Green, Red
>>
>> This was actually tried for television - by CBS. Eventually, though,
>> the FCC reconsidered, and NBC's color system, "compatible color",
>> won out, as NTSC. Europe waited a while and went with PAL and
>> SECAM.
>
> Doesn't NTSC stand for "Never The Same Color"?
>
Or the alternative "Never Twice the Same Color".

It is about as horrible as the prevailing Norwegian electricity setup,
with 230-240V 3-phase and no defined ground, just a floating wire in the
more or less center of the phase triangle.

New developements use 400V with 5 wires, where you can pull out 240V
between ground and any of the phase wires.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Upcoming DFP support in clang/LLVM

<86r1583uqa.fsf@linuxsc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25087&group=comp.arch#25087

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Thu, 05 May 2022 07:43:57 -0700
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <86r1583uqa.fsf@linuxsc.com>
References: <t4qm5s$8rv$1@dont-email.me> <memo.20220503192241.8344H@jgd.cix.co.uk> <t4s699$ra2$1@dont-email.me> <9c5f44df-efca-4fb3-845e-b37589b7097fn@googlegroups.com> <t50cpf$1tnk$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="dc8b43139406aeb6e102a462a61968fc";
logging-data="1233"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5OXRLx/pMaUCCsWZXyJtDCfPsv7q37TQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:0T09pkluq2UUHZ7Q/8zsIwlZS0M=
sha1:ybLIKF/z3TcFNMLCSsr9hC/ZAV0=
 by: Tim Rentsch - Thu, 5 May 2022 14:43 UTC

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> MitchAlsup wrote:
>
>> When forced to use C++, I use the C subset.
>
> As I've stated before I tend to use C(+), where all the (+) features
> have typically been included in more recent updates to the C standard.

Can you be more specific? Presumably that includes many or
most of the features introduced in C99. Do you know which
ones (or which ones not)? Do you use any of the features
introduced in C11 (or later?)?.

Re: Upcoming DFP support in clang/LLVM

<a3a2ee8a-83c2-4a4c-b8da-cbbcbd27e866n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25091&group=comp.arch#25091

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:4050:b0:69f:f11b:8814 with SMTP id i16-20020a05620a405000b0069ff11b8814mr13578012qko.747.1651775234251;
Thu, 05 May 2022 11:27:14 -0700 (PDT)
X-Received: by 2002:a05:6870:f2a9:b0:e5:8106:4486 with SMTP id
u41-20020a056870f2a900b000e581064486mr2960488oap.109.1651775233733; Thu, 05
May 2022 11:27:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 5 May 2022 11:27:13 -0700 (PDT)
In-Reply-To: <86r1583uqa.fsf@linuxsc.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4ef:e7b7:c308:23a3;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4ef:e7b7:c308:23a3
References: <t4qm5s$8rv$1@dont-email.me> <memo.20220503192241.8344H@jgd.cix.co.uk>
<t4s699$ra2$1@dont-email.me> <9c5f44df-efca-4fb3-845e-b37589b7097fn@googlegroups.com>
<t50cpf$1tnk$1@gioia.aioe.org> <86r1583uqa.fsf@linuxsc.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a3a2ee8a-83c2-4a4c-b8da-cbbcbd27e866n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 05 May 2022 18:27:14 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 33
 by: MitchAlsup - Thu, 5 May 2022 18:27 UTC

On Thursday, May 5, 2022 at 9:45:04 AM UTC-5, Tim Rentsch wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> > MitchAlsup wrote:
> >
> >> When forced to use C++, I use the C subset.
> >
> > As I've stated before I tend to use C(+), where all the (+) features
> > have typically been included in more recent updates to the C standard.
> Can you be more specific? Presumably that includes many or
> most of the features introduced in C99. Do you know which
> ones (or which ones not)? Do you use any of the features
> introduced in C11 (or later?)?.
<
I use:
volatile (exceedingly lightly)
[u]type_t's
//
compound literals (lightly)

I do not use:
inline
complex
variable length arrays array[n] {I still use K&R C array[];}
designated initializers
variadic macros
restrict
IEEE FP extensions

The only places I define variables is at the front of a block and in
for-loop statements.

I like { to line up vertically with }

I don't think I use any of the C11 additions.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor