* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
@ 2023-08-03 21:48 Noel Chiappa
0 siblings, 0 replies; 17+ messages in thread
From: Noel Chiappa @ 2023-08-03 21:48 UTC (permalink / raw)
To: tuhs; +Cc: jnc
> From: Will Senn
> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
There are two different cases: i) support of split I+D in the kernel, and
ii) support of split I+D in user processes. Both arrived with V6; the
V5 source:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/main.c
(former for kernel; later for users) shows no sign of it.
> From: Kenneth Goodwin <kennethgoodwin56@gmail.com>
> 1. I don't think the 11/45 had split I & d.
> But I could be wrong.
> That did not appear until the 11/70
You are wrong.
The chief differences between the KB11-A&-D of the -11/45 and the -B&-C of
the -11/70 were i) the latter had a cache, and ii) the latter used the 32-bit
wide Main Memory Bus, which also allowed up to 4 Mbytes of main memory.
Detail here:
https://gunkies.org/wiki/PDP-11/70
along with a couple of lesser differences.
> From: "Ronald Natalie"
> with only 8 segment registers combined for code, data, and stack
I think you meant for code, data, and user block.
> The 55 (just a tweaked 45)
The /50 and /55 had the identical KB11-A&-D of the /45; the difference was
that they came pre-configured with Fastbus memory.
> In addition the 23/24/J-11 and those derived processors did.
No; the F-11 processors did not support I&D, the J-11 did.
Noel
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
@ 2023-08-04 21:40 Noel Chiappa
0 siblings, 0 replies; 17+ messages in thread
From: Noel Chiappa @ 2023-08-04 21:40 UTC (permalink / raw)
To: tuhs; +Cc: jnc
> From: Clem Cole
> first two subsystems for the 11 that ran out of text space were indeed
> vi and Pascal subsystems
Those were at Berkeley. We've established that S-I&D were in V6 when it was
released in May, 1975 - so my question is 'what was Bell doing in 1975 that
needed more than 64KB?'
The kernel, yeah, it could definitely use S-I&D on a larger system
(especially when you remember that stock V6 didn't play any tricks with
overlays, and also dedicated one segment - the correct term, used in the 1972
-11/45 processor manual - to the user structure, and one to the I/O page,
limiting the non-S-I&D kernel to 48KB). But what user commands?
It happens that I have a complete dump of one of the MIT systems, so I had a
look to see what _we_ were running S-I&D on. Here's the list from /bin (for
some reason that machine doesn't have a /usr/bin):
a68
a86
c86
emacs
lisp
ndd
send
teco
The lisp wasn't a serious use; I think the only thing we ever used it for was
'doctor'. So, two editors, a couple of language tools, an email tool (not
sure why that one got it - maybe for creating large outgoing messages). (The
ndd is probably to allow the biggest possible buffers.)
Nothing in /etc, and in /lib, just lint1 and lint2 (lint, AFAICT, post-dates
V6). Not a lot.
So now I'm really curious what Bell was using S-I&D for. (If I weren't lazy,
I'd pull the V6 distro - which is only available as RK images, and individual
files, alas - and look in /bin and everywhere and see if I can find anything.
I suspect not, though.)
Anyone have any guesses/suggestions? Maybe some custom applications?
Noel
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
@ 2023-08-03 23:14 Steve Simon
0 siblings, 0 replies; 17+ messages in thread
From: Steve Simon @ 2023-08-03 23:14 UTC (permalink / raw)
To: tuhs
not quite split i and d but i do have a memory of some code which could run in three parts as overlays.
this could have been through exec’ing the next overlay with an appropriate argv and a pipe or file of data, or, perhaps there was some kernel support for overlays in early unix.
anyone seen evidence of this?
sadly i cannot remember where i saw it, i want to say it was a versatex printer driver but i am pretty sure that is rubbish.
-Steve
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
@ 2023-08-03 23:10 Noel Chiappa
2023-08-03 23:42 ` Warner Losh
0 siblings, 1 reply; 17+ messages in thread
From: Noel Chiappa @ 2023-08-03 23:10 UTC (permalink / raw)
To: tuhs; +Cc: jnc
> From: Clem Cole
> A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
> Strecker that he could implement an 11 on a single"hex high" CPU board
> if he got rid of the lights and switches. He ran out of room to
> implement seperate I/D, so it became an 11/40 class [and it has an
> 8008-1 that runs the front panel].
I don't know about the Strecker story, but the first PDP-11 CPU on a single
card (a hex card) was the KD11-D:
https://gunkies.org/wiki/KD11-D_CPU
of the -11/04. It didn't have _any_ memory management, though (or a front
panel; to get that, you had to use the KY"11-LB:
https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console
which added another quad card). The first -11 CPU i) on a single card and
ii) with memory management was the FDF11-A:
https://gunkies.org/wiki/KDF11-A_CPU
The first -11 CPU i) on a single card and ii) with split I+D memory
management was the KDJ11-A.
> It was not until 11/44 that DEC was able to make a hex height
> implementation of the 11 that managed to cram a full 11/70 into that
> system.
I'm not sure what your point is here? The KD11-Z CPU of the -11/44:
https://gunkies.org/wiki/KD11-Z_CPU
was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex
cards). Floating point was an extra card; CIS was 2 more.
> if you look at the link line of sys/run the 45 does not have -i
Split I+D for the kernel was not supported by the linker in V6; a combination
of 'sysfix' (a special post-processor, which took as input a relocatable
linked image) and code in m45.s was needed.
https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition
https://gunkies.org/wiki/UNIX_V6_memory_layout
The code in m45.s to handle split I+D in the kernel:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
starts at 'start:' and is adequately commented to tell you what it's doing
when it plays around with kernel memory.
> From: Will Senn
> with I/D, you can use 64k for I and 64k for D. Was that it, or were
> there other tricks to get even more allocated
I have this vague memory that someone (Berkeley, I think?) added support for
automatic code overlays in user processes. The programmer had to decide which
modules went in which overlays, but after that it was all automagic. There
was a 4xx code allocated to them.
I think the support for that (in e.g. the linker) was somehow involved with
the use of overlays in the kernel, but I don't know the details (nothing
after V6 is at all interesting to me).
> didn't the 11 max out at 256k)?
You need to distinguish between i) the amount of memory the machine could
handle, and ii) the amount of memory that running code could 'see' at any
instant. The latter was always either 64KB, or 64KB+64KB (with split I+D
turned on, on CPUs which supported it).
The former, it's complicated. Mostly, on UNIBUS only machines, it was 256KB.
(Although there was the Able ENABLE:
https://gunkies.org/wiki/Able_ENABLE
which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70,
as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44
had an Extended UNIBUS, and could also handle up to 4MB (but only after the
MS11-P became available; there were only 4 main memory slots in the
backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the
KB11-A (Revision A), which only suppported 256 KB, all later revisions and
CPUs could also handle up to 4MB.
Noel
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 23:10 Noel Chiappa
@ 2023-08-03 23:42 ` Warner Losh
0 siblings, 0 replies; 17+ messages in thread
From: Warner Losh @ 2023-08-03 23:42 UTC (permalink / raw)
To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]
On Thu, Aug 3, 2023, 5:10 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> > From: Clem Cole
>
> > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
> > Strecker that he could implement an 11 on a single"hex high" CPU
> board
> > if he got rid of the lights and switches. He ran out of room to
> > implement seperate I/D, so it became an 11/40 class [and it has an
> > 8008-1 that runs the front panel].
>
> I don't know about the Strecker story, but the first PDP-11 CPU on a single
> card (a hex card) was the KD11-D:
>
> https://gunkies.org/wiki/KD11-D_CPU
>
> of the -11/04. It didn't have _any_ memory management, though (or a front
> panel; to get that, you had to use the KY"11-LB:
>
> https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console
>
> which added another quad card). The first -11 CPU i) on a single card and
> ii) with memory management was the FDF11-A:
>
> https://gunkies.org/wiki/KDF11-A_CPU
>
> The first -11 CPU i) on a single card and ii) with split I+D memory
> management was the KDJ11-A.
>
>
> > It was not until 11/44 that DEC was able to make a hex height
> > implementation of the 11 that managed to cram a full 11/70 into that
> > system.
>
> I'm not sure what your point is here? The KD11-Z CPU of the -11/44:
>
> https://gunkies.org/wiki/KD11-Z_CPU
>
> was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex
> cards). Floating point was an extra card; CIS was 2 more.
>
>
> > if you look at the link line of sys/run the 45 does not have -i
>
> Split I+D for the kernel was not supported by the linker in V6; a
> combination
> of 'sysfix' (a special post-processor, which took as input a relocatable
> linked image) and code in m45.s was needed.
>
> https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition
> https://gunkies.org/wiki/UNIX_V6_memory_layout
>
> The code in m45.s to handle split I+D in the kernel:
>
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
>
> starts at 'start:' and is adequately commented to tell you what it's doing
> when it plays around with kernel memory.
>
>
>
> > From: Will Senn
>
> > with I/D, you can use 64k for I and 64k for D. Was that it, or were
> > there other tricks to get even more allocated
>
> I have this vague memory that someone (Berkeley, I think?) added support
> for
> automatic code overlays in user processes. The programmer had to decide
> which
> modules went in which overlays, but after that it was all automagic. There
> was a 4xx code allocated to them.
>
> I think the support for that (in e.g. the linker) was somehow involved with
> the use of overlays in the kernel, but I don't know the details (nothing
> after V6 is at all interesting to me).
>
V7 had a number of patches for MENLO_LINKER or MENLO_OVERLAY that Berkeley
integrated into the tree, but I'm not sure they wrote it. Their hacks were
usually UCB_something...
Warner
> didn't the 11 max out at 256k)?
>
> You need to distinguish between i) the amount of memory the machine could
> handle, and ii) the amount of memory that running code could 'see' at any
> instant. The latter was always either 64KB, or 64KB+64KB (with split I+D
> turned on, on CPUs which supported it).
>
> The former, it's complicated. Mostly, on UNIBUS only machines, it was
> 256KB.
> (Although there was the Able ENABLE:
>
> https://gunkies.org/wiki/Able_ENABLE
>
> which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70,
> as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44
> had an Extended UNIBUS, and could also handle up to 4MB (but only after the
> MS11-P became available; there were only 4 main memory slots in the
> backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the
> KB11-A (Revision A), which only suppported 256 KB, all later revisions and
> CPUs could also handle up to 4MB.
>
> Noel
>
[-- Attachment #2: Type: text/html, Size: 5787 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
@ 2023-07-30 23:59 Erik E. Fair
2023-08-01 10:58 ` Erik E. Fair
0 siblings, 1 reply; 17+ messages in thread
From: Erik E. Fair @ 2023-07-30 23:59 UTC (permalink / raw)
To: George Michaelson; +Cc: tuhs
Date: Mon, 31 Jul 2023 09:34:56 +1000
From: George Michaelson <ggm@algebras.org>
[...]
Execute on read is just awful. But, now we have HTML to track "they
read it" through URL fetch.
And then the utterly disastrous: JavaScript. It should be *eliminated*
from the WWW as the gross security violation it is.
"don't run software from strangers",
Erik Fair
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
@ 2023-08-01 10:58 ` Erik E. Fair
2023-08-02 0:37 ` Dave Horsfall
0 siblings, 1 reply; 17+ messages in thread
From: Erik E. Fair @ 2023-08-01 10:58 UTC (permalink / raw)
To: Marc Donner; +Cc: tuhs
Date: Tue, 1 Aug 2023 05:22:17 -0400
From: Marc Donner <marc.donner@gmail.com>
Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?)
that was intended to be more functional than raw text but safer
than free execution of unknown code. I disremember the details.
I don't think it ever got traction.
You remember correctly. It got stomped by those of us in the IETF MIME working group with approximately the same forceful negative reaction as you've seen here to Mike Lesk's idea of instantly executed Unix commands in e-mail.
I'm hardly innocent of this - while writing & operating the AppleLink/Internet e-mail gateway at Apple in the 1990s, I discovered that I could download the entire user directory from AppleLink (over 50k users: all Apple employees, Apple 3rd-party developers, Apple retail dealers - the whole "Apple Federation" at that time was on AppleLink), which included both usernames and "full name" fields, which could provide the basis for an AppleLink directory lookup service on the Internet. I figured it'd be easy to use FINGER & WHOIS as the protocol ports since the outputs of those are basically unstructured (unspecified) ASCII text, e.g. "finger fair@applelink.apple.com" would return a list of all usernames and full names matching "fair".
I was writing in Perl because e-mail gatewaying is primarily about string handling, and it sucks to write in C for that. The best performing way to implement the text search was to use its eval() function with a regex constructed from the network protocol input. I tested it, and it worked great, but I bet you can guess where this is going - how to perfectly sanitize the search term inputs taken directly from the net so they don't become arbitrary Perl code?
I never deployed it, partly because I couldn't convince myself I'd made the service completely secure, and partly as a privacy matter: finger (especially after the 1989 Morris Worm & the increasing amounts of e-mail spam) was not a service that sites were offering any longer because there were too many bad actors on the Internet, and it just wasn't a good idea to be as open & trusting as the ARPANET had been. I lament the passing of that culture from time to time.
I think anyone with a modicum of experience in computer & systems security can instantly recognize the dangers in executable code transmitted unsolicited to unwary recipients and automatically executed without prior, explicit permission, and works to stop anything along those lines from becoming standard practice because, despite all the protestations that "it's run in a sandbox, it's safe!", the proponents can never prove their case beyond reasonable doubt.
How many bugs were discovered in the "restricted shell" (rsh) over the years?
Sometimes we fail to prevent such bad ideas from being implemented: JavaScript in HTML/HTTP is one such. What concerns me these days is how often JavaScript is showing up in text/html e-mail. At least visiting a website (URL) with a web browser is, to some degree, an act of volition. Particularly with MIME, Internet e-mail has to be parsed and presented (and which HTML parsers these days do not also include a JavaScript interpreter?), not merely spewed to a presumed-ASCII (OK, UTF-8) terminal. Even simple spew could be dangerous: who remembers "intelligent terminal" transmit-back codes and the mischief those caused?
IIRC, the question we posed to Nathaniel was: "do we really want to enable letter bombs?"
Some of us also remembered (and possibly referenced) the UNAbomber.
Erik
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
2023-08-01 10:58 ` Erik E. Fair
@ 2023-08-02 0:37 ` Dave Horsfall
2023-08-02 14:52 ` Ron Natalie
0 siblings, 1 reply; 17+ messages in thread
From: Dave Horsfall @ 2023-08-02 0:37 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Tue, 1 Aug 2023, Erik E. Fair wrote:
> Even simple spew could be dangerous: who remembers "intelligent
> terminal" transmit-back codes and the mischief those caused?
ASCII bombs were fairly popular in the old MS-DOS BBS days (format the
disk, anyone?), and it was possible over packet radio too (sort of a BBS
via Amateur i.e. "ham" radio).
-- Dave (vk2kfu)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
2023-08-02 0:37 ` Dave Horsfall
@ 2023-08-02 14:52 ` Ron Natalie
2023-08-02 21:14 ` Grant Taylor via TUHS
0 siblings, 1 reply; 17+ messages in thread
From: Ron Natalie @ 2023-08-02 14:52 UTC (permalink / raw)
To: Dave Horsfall, The Eunuchs Hysterical Society
ASCII Bombs? Like my Letter Bomb Transport Protocol (LBTP)?
https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ
It seems to have lost something in the formatting (the leading spaces
were all removed).
------ Original Message ------
From "Dave Horsfall" <dave@horsfall.org>
To "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/1/23, 8:37:20 PM
Subject [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric
Allman
>On Tue, 1 Aug 2023, Erik E. Fair wrote:
>
>> Even simple spew could be dangerous: who remembers "intelligent
>> terminal" transmit-back codes and the mischief those caused?
>
>ASCII bombs were fairly popular in the old MS-DOS BBS days (format the
>disk, anyone?), and it was possible over packet radio too (sort of a BBS
>via Amateur i.e. "ham" radio).
>
>-- Dave (vk2kfu)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
2023-08-02 14:52 ` Ron Natalie
@ 2023-08-02 21:14 ` Grant Taylor via TUHS
2023-08-02 22:20 ` segaloco via TUHS
0 siblings, 1 reply; 17+ messages in thread
From: Grant Taylor via TUHS @ 2023-08-02 21:14 UTC (permalink / raw)
To: tuhs
On 8/2/23 9:52 AM, Ron Natalie wrote:
> ASCII Bombs? Like my Letter Bomb Transport Protocol (LBTP)?
>
> https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ
~chuckle~
> It seems to have lost something in the formatting (the leading spaces
> were all removed).
Ya....
People think I'm weird for not liking languages that use white space as
structural definition. Frequently those people have not experienced
such a failure as what has happened to your ASCII Bomb.
Grant. . . .
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
2023-08-02 21:14 ` Grant Taylor via TUHS
@ 2023-08-02 22:20 ` segaloco via TUHS
2023-08-02 23:49 ` Rich Salz
0 siblings, 1 reply; 17+ messages in thread
From: segaloco via TUHS @ 2023-08-02 22:20 UTC (permalink / raw)
To: Grant Taylor; +Cc: tuhs
> People think I'm weird for not liking languages that use white space as
> structural definition.
>
> Grant. . . .
This is my chief gripe with Python, although on the flip side Python isn't the right language anyway for most scenarios where I use whitespace/indentation to imply structure the language itself can't articulate. It's meant for mainly functional programming as I understand it so the structure does enforce some stylistic practices conducive to good functional programming. Still a shame to force a particular style approach by default rather than just strongly suggest it.
What strikes me particularly odd about the Python case is that its not like that space-sensitivity evolved out of the same line of reasoning as the compulsory spacing in FORTRAN, COBOL, etc. It seems mainly to be a way to operate without code blocks, with the "blocks" being implied by indentation rather than braces, parens, or some other delimiter.
In UNIX of course we have our own little variation on this problem with make(1) and the need to tab out the rule definition. I seem to recall reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu Feldman considered undoing that but there were already users who that would've caused trouble for, so make's early, entrenched adoption stymied attempts at the time to rectify this. Anyone with better details feel free to correct me.
- Matt G.
P.S. This answer can be off list or spin off a separate thread for make junkies, but did any AT&T or BSD revision of make(1) support rule names coming from variables rather than explicitly entered?
For instance:
$(BIN): $(OBJS)
$(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS)
I used to use this in makefiles but at some point, I think with one of the BSDs, it balked at the idea of a variable rule name and so it fell out of my practice in trying to avoid GNUisms.
It's been a while but I feel like I ran through and tried this on V7, System III, and PDP-11 System V and all of them were unhappy about that construct. I can try and get on the LCMs 3B400 later to see what SVR3 does. I don't remember which of the BSDs (if not multiple) I ran into that issue on initially, but I can't imagine one of the major streams would work that in without the other two wanting to copy their notes.
Maybe an alternative question is if folks are aware of make implementations besides GNU that *do* support that sort of thing.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman
2023-08-02 22:20 ` segaloco via TUHS
@ 2023-08-02 23:49 ` Rich Salz
2023-08-03 0:51 ` [TUHS] Re: python Larry McVoy
0 siblings, 1 reply; 17+ messages in thread
From: Rich Salz @ 2023-08-02 23:49 UTC (permalink / raw)
To: segaloco; +Cc: Grant Taylor, tuhs
[-- Attachment #1: Type: text/plain, Size: 177 bytes --]
> [Python is] meant for mainly functional programming as I understand it
Not true. It has some neat functional features (list comprehensions) but
that's not really its intent.
[-- Attachment #2: Type: text/html, Size: 233 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: python
2023-08-02 23:49 ` Rich Salz
@ 2023-08-03 0:51 ` Larry McVoy
2023-08-03 2:07 ` Clem Cole
0 siblings, 1 reply; 17+ messages in thread
From: Larry McVoy @ 2023-08-03 0:51 UTC (permalink / raw)
To: Rich Salz; +Cc: segaloco, Grant Taylor, tuhs
On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
> > [Python is] meant for mainly functional programming as I understand it
>
> Not true. It has some neat functional features (list comprehensions) but
> that's not really its intent.
I've really tried to like python but any language that doesn't has printf
as builtin is not for me. Yes, I know about their library printf but it
is weird.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: python
2023-08-03 0:51 ` [TUHS] Re: python Larry McVoy
@ 2023-08-03 2:07 ` Clem Cole
2023-08-03 16:57 ` [TUHS] Re: [TULSA] " Phil Budne
0 siblings, 1 reply; 17+ messages in thread
From: Clem Cole @ 2023-08-03 2:07 UTC (permalink / raw)
To: Larry McVoy; +Cc: Grant Taylor, segaloco, tuhs
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
IMO (Like Larry) no printf stinks. But the real killer for my sustain for
Python is the use white space and being typeless. My daughter loves it
for her cloud development and we argue a bit. But it was the first
language she really mastered in college and she never took a competitive
languages course so I’m not so sure really had experienced much beyond it
for real programs. Maybe I’m just an old fart but between C, Go and Rust
I’m pretty good. I do write scripts in Bourne shell and or awk truth be
known.
On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy <lm@mcvoy.com> wrote:
> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
> > > [Python is] meant for mainly functional programming as I understand it
> >
> > Not true. It has some neat functional features (list comprehensions) but
> > that's not really its intent.
>
> I've really tried to like python but any language that doesn't has printf
> as builtin is not for me. Yes, I know about their library printf but it
> is weird.
> --
> ---
> Larry McVoy Retired to fishing
> http://www.mcvoy.com/lm/boat
>
--
Sent from a handheld expect more typos than usual
[-- Attachment #2: Type: text/html, Size: 1708 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: [TULSA] Re: python
2023-08-03 2:07 ` Clem Cole
@ 2023-08-03 16:57 ` Phil Budne
2023-08-03 17:00 ` Rich Salz
0 siblings, 1 reply; 17+ messages in thread
From: Phil Budne @ 2023-08-03 16:57 UTC (permalink / raw)
To: tuhs
I come not to praise Python...
I picked up Python (v1) in the early 'aughts as a more readable
alternative to Perl and Ruby (non-alphanumerical variable names are a
non-starter for me).
I agree that using indentation alone to determine block structure was
an interesting thought experiment, but TERRIBLE in practice (you might
as well throw away any editing buffer where the phone rang after you
cut and paste, but before re-indenting code), BUT it does prevent (in
a rather fascist way) formatting abominations like the C code in
procmail and SimH.
Python continues to evolve, so it's a moving target, and the argument
that there is ONE RIGHT WAY(TM) to do anything is not only long dead,
but now deeply putrid (much as with the multiple doublings in the size
of C++ and later C++ + STL books).
I used to regard the Python2/Python3 world breakage as a fiasco, but
considering how quickly the language is mutating, perhaps is was a
good fiasco if it lowered the mutation rate for number of years.
On the subject of "no printf", there is not one, not two, but THREE
ways to format strings, easily compounded with print:
print("%s %s" % ("hello", "world"))
print("{1} {two}".format("hello", two="world"))
print(f"{greeting} {populace}")
I'm pretty sure the last method (which initially made me vomit, due to
violating my hardwired ideas about complicating the lexer, as if it
can even be thought of as a separate layer), BUT I Seem To Recall that
it allows a class to implement a formatting method, which may (or may
not) work for complex numbers.
Type "hinting" has been mentioned: again, it's almost like a whole new
version of the language. You need to pick a type checker, and likely
turn up the knobs to achieve any actual safety, and then deal with the
fact that not all packages supply hints out of the box. It kind of
offers the desert-topping/floor-wax dichotomy: You can easily/quickly
write small programs with dynamic typing for quick one-offs, AND write
better armored code for libraries & production code.
On tabs vs spaces: Python3 forbids mixing them. Again, fascist, but
"it's for your own good".
So yes, Python sucks, but I continue using it, and unlike sendmail
(which I continue to run, as I have a 200+ line .mc file it would take
me at LEAST a week to replicate the effects of in another MTA), I
don't tell people Python is unsuitable at any speed.
I'd probably happily write Go or Rust, given a situation (existing
project/program) where its use was inevitable, and I DO have a program
I think is a good candidate for rewriting in Go, but on the whole,
it's a useful tool for many kinds of programmers, and in many
situations, which I think is somewhat remarkable.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: [TULSA] Re: python
2023-08-03 16:57 ` [TUHS] Re: [TULSA] " Phil Budne
@ 2023-08-03 17:00 ` Rich Salz
2023-08-03 20:35 ` [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Will Senn
0 siblings, 1 reply; 17+ messages in thread
From: Rich Salz @ 2023-08-03 17:00 UTC (permalink / raw)
Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
What, we all need something to kick now that we've beaten sendmail? How
about something unix, ideally a decade old?
[-- Attachment #2: Type: text/html, Size: 148 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 17:00 ` Rich Salz
@ 2023-08-03 20:35 ` Will Senn
2023-08-03 21:05 ` [TUHS] " Kenneth Goodwin
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Will Senn @ 2023-08-03 20:35 UTC (permalink / raw)
To: tuhs
Does unix (v7) know about the PDP-11 45's split I/D space through
configuration or is it convention and programmer's responsibility to
know and manage what's actually available?
Will
On 8/3/23 12:00, Rich Salz wrote:
> What, we all need something to kick now that we've beaten sendmail?
> How about something unix, ideally a decade old?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 20:35 ` [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Will Senn
@ 2023-08-03 21:05 ` Kenneth Goodwin
2023-08-03 21:10 ` Ronald Natalie
2023-08-03 21:05 ` Ronald Natalie
2023-08-03 21:44 ` Clem Cole
2 siblings, 1 reply; 17+ messages in thread
From: Kenneth Goodwin @ 2023-08-03 21:05 UTC (permalink / raw)
To: Will Senn; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
At the risk of exposing my ignorance and thus being events long long ago in
history....
And my mind now old and feeble...
😆 🤣
1. I don't think the 11/45 had split I & d.
But I could be wrong.
That did not appear until the 11/70
And was in the later generation 11/44 several years later.
2. The kernel determined it by MMU type and managed it solely. The
assembler and loader always built the binary object file as the three
sections - instructions, data and bss spaces so loading an object file
could be done on any platform.
Programmers generally did not worry about the underlying hardware
3. I don't recall if a systype style system call was available in v7 to
give you a machine type to switch off of.
With something like that you could determine memory availability hard
limits on the DATA/bss side if you needed to.
But that was also easily determined by a allocation failure in malloc/sbrk
with an out of memory error.
If you really needed to know availability, you could have a start up
subroutine that would loop trying to malloc ever decreasing memory sizes
until success and until out of available memory error.
Then release it all back via free(). Or manage it internally.
As I recall however vaguely, there was an attempt to split the kernel into
two pieces. One running in kernel mode and one running in supervisor mode
in order to double the amount of available instruction and data spaces for
the operating system. I recall playing around with what was there trying to
get it to work right.
I was trying to support over 200 users on a pdp 11/70 at the time running a
massive insurance database system.
On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
>
> Will
>
> On 8/3/23 12:00, Rich Salz wrote:
> > What, we all need something to kick now that we've beaten sendmail?
> > How about something unix, ideally a decade old?
>
>
[-- Attachment #2: Type: text/html, Size: 2958 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 21:05 ` [TUHS] " Kenneth Goodwin
@ 2023-08-03 21:10 ` Ronald Natalie
2023-08-03 21:16 ` Warner Losh
2023-08-03 22:34 ` Kenneth Goodwin
0 siblings, 2 replies; 17+ messages in thread
From: Ronald Natalie @ 2023-08-03 21:10 UTC (permalink / raw)
To: Kenneth Goodwin, Will Senn; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]
Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that
it did have split I/D. V6 supported split I/D for user mode programs.
The kernel originally wasn’t split I/D. Version 7, if I’m recalling
properly, did run the kernel split I/D on the 45 and 70.
------ Original Message ------
From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
To "Will Senn" <will.senn@gmail.com>
Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/3/23, 5:05:31 PM
Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death
of the python... thread)
>At the risk of exposing my ignorance and thus being events long long
>ago in history....
>And my mind now old and feeble...
>
>😆 🤣
>
>1. I don't think the 11/45 had split I & d.
>But I could be wrong.
>That did not appear until the 11/70
>And was in the later generation 11/44 several years later.
>
>2. The kernel determined it by MMU type and managed it solely. The
>assembler and loader always built the binary object file as the three
>sections - instructions, data and bss spaces so loading an object file
>could be done on any platform.
>Programmers generally did not worry about the underlying hardware
>
>3. I don't recall if a systype style system call was available in v7 to
>give you a machine type to switch off of.
>
>With something like that you could determine memory availability hard
>limits on the DATA/bss side if you needed to.
>
>But that was also easily determined by a allocation failure in
>malloc/sbrk with an out of memory error.
>
>If you really needed to know availability, you could have a start up
>subroutine that would loop trying to malloc ever decreasing memory
>sizes until success and until out of available memory error.
>Then release it all back via free(). Or manage it internally.
>
>As I recall however vaguely, there was an attempt to split the kernel
>into two pieces. One running in kernel mode and one running in
>supervisor mode in order to double the amount of available instruction
>and data spaces for the operating system. I recall playing around with
>what was there trying to get it to work right.
>I was trying to support over 200 users on a pdp 11/70 at the time
>running a massive insurance database system.
>
>On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>>Does unix (v7) know about the PDP-11 45's split I/D space through
>>configuration or is it convention and programmer's responsibility to
>>know and manage what's actually available?
>>
>>Will
>>
>>On 8/3/23 12:00, Rich Salz wrote:
>> > What, we all need something to kick now that we've beaten sendmail?
>> > How about something unix, ideally a decade old?
>>
[-- Attachment #2: Type: text/html, Size: 4845 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 21:10 ` Ronald Natalie
@ 2023-08-03 21:16 ` Warner Losh
2023-08-03 21:24 ` Ronald Natalie
2023-08-03 22:34 ` Kenneth Goodwin
1 sibling, 1 reply; 17+ messages in thread
From: Warner Losh @ 2023-08-03 21:16 UTC (permalink / raw)
To: Ronald Natalie; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]
2BSD also did split I&D in the kernel (as well as run TCP in supervisor
mode to get another I/D space). A lot of the overlays was done in the
linker, but it wasn't completely automated.
I had to tweak the overlay tables a little as I did the 2.11pl0 work since
the early stuff wasn't exactly careful about distributing the hacks to the
makefile to make it happen...
Warner
On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie <ron@ronnatalie.com> wrote:
> Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that
> it did have split I/D. V6 supported split I/D for user mode programs.
> The kernel originally wasn’t split I/D. Version 7, if I’m recalling
> properly, did run the kernel split I/D on the 45 and 70.
>
>
>
> ------ Original Message ------
> From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
> To "Will Senn" <will.senn@gmail.com>
> Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
> Date 8/3/23, 5:05:31 PM
> Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of
> the python... thread)
>
> At the risk of exposing my ignorance and thus being events long long ago
> in history....
> And my mind now old and feeble...
>
> 😆 🤣
>
> 1. I don't think the 11/45 had split I & d.
> But I could be wrong.
> That did not appear until the 11/70
> And was in the later generation 11/44 several years later.
>
> 2. The kernel determined it by MMU type and managed it solely. The
> assembler and loader always built the binary object file as the three
> sections - instructions, data and bss spaces so loading an object file
> could be done on any platform.
> Programmers generally did not worry about the underlying hardware
>
> 3. I don't recall if a systype style system call was available in v7 to
> give you a machine type to switch off of.
>
> With something like that you could determine memory availability hard
> limits on the DATA/bss side if you needed to.
>
> But that was also easily determined by a allocation failure in malloc/sbrk
> with an out of memory error.
>
> If you really needed to know availability, you could have a start up
> subroutine that would loop trying to malloc ever decreasing memory sizes
> until success and until out of available memory error.
> Then release it all back via free(). Or manage it internally.
>
> As I recall however vaguely, there was an attempt to split the kernel
> into two pieces. One running in kernel mode and one running in supervisor
> mode in order to double the amount of available instruction and data
> spaces for the operating system. I recall playing around with what was
> there trying to get it to work right.
> I was trying to support over 200 users on a pdp 11/70 at the time running
> a massive insurance database system.
>
> On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>
>> Does unix (v7) know about the PDP-11 45's split I/D space through
>> configuration or is it convention and programmer's responsibility to
>> know and manage what's actually available?
>>
>> Will
>>
>> On 8/3/23 12:00, Rich Salz wrote:
>> > What, we all need something to kick now that we've beaten sendmail?
>> > How about something unix, ideally a decade old?
>>
>>
[-- Attachment #2: Type: text/html, Size: 4995 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 21:16 ` Warner Losh
@ 2023-08-03 21:24 ` Ronald Natalie
0 siblings, 0 replies; 17+ messages in thread
From: Ronald Natalie @ 2023-08-03 21:24 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 4236 bytes --]
In fact, it was TCP (mbuf windowing) that killed the non split-I/D
systems in our installation. We were already using kernel overlays,
but with only 8 segment registers combined for code, data, and stack, we
just ran out of registers. By then the VAXEN were coming along. I
recycled the 11/34’s etc… into LOS/C Internet routers.
The 55 (just a tweaked 45) and later the 44 also had it. In addition
the 23/24/J-11 and those derived processors did.
------ Original Message ------
From "Warner Losh" <imp@bsdimp.com>
To "Ronald Natalie" <ron@ronnatalie.com>
Cc "Kenneth Goodwin" <kennethgoodwin56@gmail.com>; "Will Senn"
<will.senn@gmail.com>; "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/3/23, 5:16:25 PM
Subject Re: [TUHS] Re: Split addressing (I/D) space (inspired by the
death of the python... thread)
>2BSD also did split I&D in the kernel (as well as run TCP in supervisor
>mode to get another I/D space). A lot of the overlays was done in the
>linker, but it wasn't completely automated.
>I had to tweak the overlay tables a little as I did the 2.11pl0 work
>since the early stuff wasn't exactly careful about distributing the
>hacks to the makefile to make it happen...
>
>Warner
>
>On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie <ron@ronnatalie.com>
>wrote:
>>Having cut my UNIX teeth on the JHU 11/45, I can tell you very much
>>that it did have split I/D. V6 supported split I/D for user mode
>>programs. The kernel originally wasn’t split I/D. Version 7, if
>>I’m recalling properly, did run the kernel split I/D on the 45 and 70.
>>
>>
>>
>>------ Original Message ------
>>From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
>>To "Will Senn" <will.senn@gmail.com>
>>Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
>>Date 8/3/23, 5:05:31 PM
>>Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death
>>of the python... thread)
>>
>>>At the risk of exposing my ignorance and thus being events long long
>>>ago in history....
>>>And my mind now old and feeble...
>>>
>>>😆 🤣
>>>
>>>1. I don't think the 11/45 had split I & d.
>>>But I could be wrong.
>>>That did not appear until the 11/70
>>>And was in the later generation 11/44 several years later.
>>>
>>>2. The kernel determined it by MMU type and managed it solely. The
>>>assembler and loader always built the binary object file as the three
>>>sections - instructions, data and bss spaces so loading an object
>>>file could be done on any platform.
>>>Programmers generally did not worry about the underlying hardware
>>>
>>>3. I don't recall if a systype style system call was available in v7
>>>to give you a machine type to switch off of.
>>>
>>>With something like that you could determine memory availability hard
>>>limits on the DATA/bss side if you needed to.
>>>
>>>But that was also easily determined by a allocation failure in
>>>malloc/sbrk with an out of memory error.
>>>
>>>If you really needed to know availability, you could have a start up
>>>subroutine that would loop trying to malloc ever decreasing memory
>>>sizes until success and until out of available memory error.
>>>Then release it all back via free(). Or manage it internally.
>>>
>>>As I recall however vaguely, there was an attempt to split the
>>>kernel into two pieces. One running in kernel mode and one running in
>>>supervisor mode in order to double the amount of available
>>>instruction and data spaces for the operating system. I recall
>>>playing around with what was there trying to get it to work right.
>>>I was trying to support over 200 users on a pdp 11/70 at the time
>>>running a massive insurance database system.
>>>
>>>On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>>>>Does unix (v7) know about the PDP-11 45's split I/D space through
>>>>configuration or is it convention and programmer's responsibility to
>>>>know and manage what's actually available?
>>>>
>>>>Will
>>>>
>>>>On 8/3/23 12:00, Rich Salz wrote:
>>>> > What, we all need something to kick now that we've beaten
>>>>sendmail?
>>>> > How about something unix, ideally a decade old?
>>>>
[-- Attachment #2: Type: text/html, Size: 7172 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 21:10 ` Ronald Natalie
2023-08-03 21:16 ` Warner Losh
@ 2023-08-03 22:34 ` Kenneth Goodwin
1 sibling, 0 replies; 17+ messages in thread
From: Kenneth Goodwin @ 2023-08-03 22:34 UTC (permalink / raw)
To: Ronald Natalie; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]
Having worked on the v6 kernel on the
11/70 it was split on that version on that hardware.
On Thu, Aug 3, 2023, 5:10 PM Ronald Natalie <ron@ronnatalie.com> wrote:
> Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that
> it did have split I/D. V6 supported split I/D for user mode programs.
> The kernel originally wasn’t split I/D. Version 7, if I’m recalling
> properly, did run the kernel split I/D on the 45 and 70.
>
>
>
> ------ Original Message ------
> From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
> To "Will Senn" <will.senn@gmail.com>
> Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
> Date 8/3/23, 5:05:31 PM
> Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of
> the python... thread)
>
> At the risk of exposing my ignorance and thus being events long long ago
> in history....
> And my mind now old and feeble...
>
> 😆 🤣
>
> 1. I don't think the 11/45 had split I & d.
> But I could be wrong.
> That did not appear until the 11/70
> And was in the later generation 11/44 several years later.
>
> 2. The kernel determined it by MMU type and managed it solely. The
> assembler and loader always built the binary object file as the three
> sections - instructions, data and bss spaces so loading an object file
> could be done on any platform.
> Programmers generally did not worry about the underlying hardware
>
> 3. I don't recall if a systype style system call was available in v7 to
> give you a machine type to switch off of.
>
> With something like that you could determine memory availability hard
> limits on the DATA/bss side if you needed to.
>
> But that was also easily determined by a allocation failure in malloc/sbrk
> with an out of memory error.
>
> If you really needed to know availability, you could have a start up
> subroutine that would loop trying to malloc ever decreasing memory sizes
> until success and until out of available memory error.
> Then release it all back via free(). Or manage it internally.
>
> As I recall however vaguely, there was an attempt to split the kernel
> into two pieces. One running in kernel mode and one running in supervisor
> mode in order to double the amount of available instruction and data
> spaces for the operating system. I recall playing around with what was
> there trying to get it to work right.
> I was trying to support over 200 users on a pdp 11/70 at the time running
> a massive insurance database system.
>
> On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>
>> Does unix (v7) know about the PDP-11 45's split I/D space through
>> configuration or is it convention and programmer's responsibility to
>> know and manage what's actually available?
>>
>> Will
>>
>> On 8/3/23 12:00, Rich Salz wrote:
>> > What, we all need something to kick now that we've beaten sendmail?
>> > How about something unix, ideally a decade old?
>>
>>
[-- Attachment #2: Type: text/html, Size: 4704 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 20:35 ` [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Will Senn
2023-08-03 21:05 ` [TUHS] " Kenneth Goodwin
@ 2023-08-03 21:05 ` Ronald Natalie
2023-08-03 21:44 ` Clem Cole
2 siblings, 0 replies; 17+ messages in thread
From: Ronald Natalie @ 2023-08-03 21:05 UTC (permalink / raw)
To: Will Senn, tuhs
Both V6 and V7 used split I/D on the 45 and 70 where it as available.
You had to specify that you wanted it in your build, the choices were
the 407 flagged. a.out, which had a single text/data/bss space
(unspilt). 410 which still ran in one address space, but put the text
in read only segments so they could be shared. 411 ran the executable
in split I and D space.
The original use of the “sticky” bit in the inode mode indicated that a
410 or 411 program text would be held in swap.
-Ron
------ Original Message ------
From "Will Senn" <will.senn@gmail.com>
To tuhs@tuhs.org
Date 8/3/23, 4:35:09 PM
Subject [TUHS] Split addressing (I/D) space (inspired by the death of
the python... thread)
>Does unix (v7) know about the PDP-11 45's split I/D space through configuration or is it convention and programmer's responsibility to know and manage what's actually available?
>
>Will
>
>On 8/3/23 12:00, Rich Salz wrote:
>>What, we all need something to kick now that we've beaten sendmail? How about something unix, ideally a decade old?
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 20:35 ` [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Will Senn
2023-08-03 21:05 ` [TUHS] " Kenneth Goodwin
2023-08-03 21:05 ` Ronald Natalie
@ 2023-08-03 21:44 ` Clem Cole
2023-08-03 22:08 ` Will Senn
2 siblings, 1 reply; 17+ messages in thread
From: Clem Cole @ 2023-08-03 21:44 UTC (permalink / raw)
To: Will Senn; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
Will its a C Compiler switch (-i) and create 411 files instead of 407.
I like to refer to it as the 17th address bit.
I was first brought out with the 11/45 (which was SSI/MSI TTL), and the
biggest differences between it and the 11/40. They were both early 1970s
and both of these processors were multiple boards. By 1976, the 780 has
started and that sucked off most of the HW folks. A new hire in 1976,
Jeff Mitchell supposedly had a bet with Bill Strecker that he could
implement an 11 on a single"hex high" CPU board if he got rid of the lights
and switches. He ran out of room to implement seperate I/D, so it became
an 11/40 class [and it has an 8008-1 that runs the front panel].
The 11/70 came out between the 11/45 and the 34 and had a number of
the STAR folks on it it original but it was also multiple boards. It was
not until 11/44 that DEC was able to make a hex height implementation of
the 11 that managed to cram a full 11/70 into that system. The later J-11
chip set took things beyond the 11/70.
If you look at the conf directory in the sys sources for V6, you see m40.s
and m45.s - but if you look at the link line of sys/run the 45 does not
have -i; but if you look in sys/sys1.c you'll see the in the routine
getxfile the support for 0407/0411/0405/0410 files for user mode.
If you look at the conf directory in the sys sources for V7, you see mch.s
and m45.s its common and the makefile adds -i
ᐧ
On Thu, Aug 3, 2023 at 4:35 PM Will Senn <will.senn@gmail.com> wrote:
> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
>
> Will
>
> On 8/3/23 12:00, Rich Salz wrote:
> > What, we all need something to kick now that we've beaten sendmail?
> > How about something unix, ideally a decade old?
>
>
[-- Attachment #2: Type: text/html, Size: 3422 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 21:44 ` Clem Cole
@ 2023-08-03 22:08 ` Will Senn
2023-08-03 22:54 ` Clem Cole
0 siblings, 1 reply; 17+ messages in thread
From: Will Senn @ 2023-08-03 22:08 UTC (permalink / raw)
To: Clem Cole; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]
Clem,
Oh, so... Without I/D, you're stuck with 64k max per process, with I/D,
you can use 64k for I and 64k for D. Was that it, or were there other
tricks to get even more allocated (didn't the 11 max out at 256k)?
The kernel could be compiled either with, or without separate I/D. The
only reason not to is if you didn't have more then 64k or were there
other reasons?
So, besides the kernel what apps tended to be split? If I remember
correctly, vi was one, pascal another?
Thanks!
Will
On 8/3/23 16:44, Clem Cole wrote:
> Will its a C Compiler switch (-i) and create 411 files instead of 407.
> I like to refer to it as the 17th address bit.
>
> I was first brought out with the 11/45 (which was SSI/MSI TTL), and
> the biggest differences between it and the 11/40. They were both
> early 1970s and both of these processors were multiple boards. By
> 1976, the 780 has started and that sucked off most of the HW folks.
> A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
> Strecker that he could implement an 11 on a single"hex high" CPU board
> if he got rid of the lights and switches. He ran out of room to
> implement seperate I/D, so it became an 11/40 class [and it has an
> 8008-1 that runs the front panel].
>
> The 11/70 came out between the 11/45 and the 34 and had a number of
> the STAR folks on it it original but it was also multiple boards. It
> was not until 11/44 that DEC was able to make a hex height
> implementation of the 11 that managed to cram a full 11/70 into that
> system. The later J-11 chip set took things beyond the 11/70.
>
> If you look at the conf directory in the sys sources for V6, you see
> m40.s and m45.s - but if you look at the link line of sys/run the 45
> does not have -i; but if you look in sys/sys1.c you'll see the in the
> routine getxfile the support for 0407/0411/0405/0410 files for user mode.
>
> If you look at the conf directory in the sys sources for V7, you see
> mch.s and m45.s its common and the makefile adds -i
>
> ᐧ
>
> On Thu, Aug 3, 2023 at 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>
> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
>
> Will
>
> On 8/3/23 12:00, Rich Salz wrote:
> > What, we all need something to kick now that we've beaten sendmail?
> > How about something unix, ideally a decade old?
>
[-- Attachment #2: Type: text/html, Size: 5408 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 22:08 ` Will Senn
@ 2023-08-03 22:54 ` Clem Cole
2023-08-03 23:08 ` Dave Horsfall
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Clem Cole @ 2023-08-03 22:54 UTC (permalink / raw)
To: Will Senn; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 4384 bytes --]
ᐧ
below... [and I meant to answer the second ½ of your question before]
On Thu, Aug 3, 2023 at 6:09 PM Will Senn <will.senn@gmail.com> wrote:
> Clem,
>
> Oh, so... Without I/D, you're stuck with 64k max per process, with I/D,
> you can use 64k for I and 64k for D.
>
Exactly but ... more in a minute.
> Was that it, or were there other tricks to get even more allocated (didn't
> the 11 max out at 256k)?
>
Different issues... the MMU on the 40 class and the 45/55 allows 256K [18
bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers had
18 bits of address and RH70 controllers could support 22 bits of extended
addresses - see the processor and peripheral handbooks for details [or I
can explain offline].
What the PDP-11 books calls 'pages' are 64-byte segments. So the MMU is
set up to allow the processor to address 64K or 64KI/64KD at the time,
depending on if you have the I/D hardware, and the MMU is set up as to
which 'pages' are being addressed.
But you could overlay things ... [0405 files] with 'thunks'.
So to allow a process (or the kernel) to have more than 64K, overlays can
be loaded into memory and since the total physical space memory space is
either 18 or 22 bits, if the kernel supports overlays - processes could get
bigger [which is part of your first question].
V7 was when 0405 [text only] overlays were added. With DEC's release of
v7m - Fred Cantor rewrote the overlay code and they became more general
[and that would go into 2.9BSD].
So the programmer needs to decide what you wanted to put into what
overlay. For processes, the kernel can swap out segments and replace them
as needed. The key is that link needs to generate near/far style calls
and it can be a PITA. If you want to access a routine that is not
currently mapped into memory, the 'thunk' needs to ask the OS to switch it.
Great thought of what was going to be stored where.
>
> The kernel could be compiled either with, or without separate I/D. The
> only reason not to is if you didn't have more then 64k or were there other
> reasons?
>
Well by V6, UNIX needed at least 64K of physical memory and it was really
slow with anything less than 256K. For the kernel, using I/D allowed the
kernel to grow more easily. By the time of trying to cram networking into
it, running on anything less than an 11/44 was pretty hard.
That said, Able made an alternate MMU called the ENABLE that allow 4M of
memory on a Unibus system. It worked at a cache/bus repeater. So you set
the internal MMU to point to it and then use its MMU. Very cool and a
soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in
Teklabs with the first Enable board.
For whatever its worth, even with 4M the kernel had started to become a
problem for V7 on an 11/70. Data buffers eat a lot of memory.
>
> So, besides the kernel what apps tended to be split? If I remember
> correctly, vi was one, pascal another?
>
Anything that started to get big ;-)
Ppeople ran out of data space and text space from 64K fairly fast. With
the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away.
Rob has an excellent paper -> "cat -v considered harmful" BSD UNIX, and
the Vaxen greatly fueled that. Adding features and thinking less about
what functionality was really needed started to get lost [so now we have
Gnu - but I digress]. Werner and the BSD 2.9 folks are to be commended for
what they did with so few resources. They moved things back from the Vax
by using the overlays, but if you were to have any semblance of
performance, you need the overlays to stay resident so you need that full
4M of memory.
As for this specific question first two subsystems for the 11 that ran out
of text space were indeed vi and Pascal subsystems (Joy having had his hand
in both, BTW). But they were hardly the only ones once the genie was out
of the bottle. Data space quickly became the real issue. People really
wanted larger heaps in particular. In fact, by the 1990s, I knew of few
programs that run out of 32-bit worth of text space, but many that started
to run out of 32-bits of data space -> hence Alpha. But BTW: DEC took a
performance hit originally, and there was a huge discussion at the time if
64-bits was really needed.
ᐧ
[-- Attachment #2: Type: text/html, Size: 9286 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 22:54 ` Clem Cole
@ 2023-08-03 23:08 ` Dave Horsfall
2023-08-03 23:15 ` Clem Cole
2023-08-04 0:38 ` John Cowan
2 siblings, 0 replies; 17+ messages in thread
From: Dave Horsfall @ 2023-08-03 23:08 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Thu, 3 Aug 2023, Clem Cole wrote:
> For whatever its worth, even with 4M the kernel had started to become a
> problem for V7 on an 11/70. Data buffers eat a lot of memory.
We at UNSW had a kludge for that; the global symbol "b" (similar to "u")
was mapped by KISA5 into the current buffer header. Having dozens of
buffers on a 40-class machine was really something...
-- Dave
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 22:54 ` Clem Cole
2023-08-03 23:08 ` Dave Horsfall
@ 2023-08-03 23:15 ` Clem Cole
2023-08-04 0:38 ` John Cowan
2 siblings, 0 replies; 17+ messages in thread
From: Clem Cole @ 2023-08-03 23:15 UTC (permalink / raw)
To: Will Senn; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 5645 bytes --]
I probably should add one more thing... RT11 and RSX, and in particular
the DEC FTN compiler, supported thunks and overlays - i.e. larger-sized
programs before UNIX did. IIRC, they needed them because by then the FTN
subsystem needed overlays to run itself. So .. assuming my memory is
correct, this was the reason why Fred rewrote the V7 code, and DEC pushed
it out as part of the v7m release. Ken's original overlay support code was
not sufficient for the DEC language tools.
I don't remember if Ultrix-11 or v7m for that matter, ultimately got the
FTN compiler. That said, Paul W might remember as he did the linker work
for Ultrix moving the VMS linker to Ultrix to support the 'Technical
Languages Group' (TLG ). Utrix-32 certainly did get FTN I think a couple
of other of the RSX and RSTS languages, but my memory of Fred's work was to
support overlays in V7 so it could support it. This was all during the
Unix wars inside of DEC. Fred was part of the 'Telephone Industries Group'
(TIG) in MRK.
ᐧ
On Thu, Aug 3, 2023 at 6:54 PM Clem Cole <clemc@ccc.com> wrote:
>
> ᐧ
> below... [and I meant to answer the second ½ of your question before]
>
> On Thu, Aug 3, 2023 at 6:09 PM Will Senn <will.senn@gmail.com> wrote:
>
>> Clem,
>>
>> Oh, so... Without I/D, you're stuck with 64k max per process, with I/D,
>> you can use 64k for I and 64k for D.
>>
> Exactly but ... more in a minute.
>
>
>
>
>> Was that it, or were there other tricks to get even more allocated
>> (didn't the 11 max out at 256k)?
>>
> Different issues... the MMU on the 40 class and the 45/55 allows 256K [18
> bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers
> had 18 bits of address and RH70 controllers could support 22 bits of
> extended addresses - see the processor and peripheral handbooks for details
> [or I can explain offline].
>
> What the PDP-11 books calls 'pages' are 64-byte segments. So the MMU is
> set up to allow the processor to address 64K or 64KI/64KD at the time,
> depending on if you have the I/D hardware, and the MMU is set up as to
> which 'pages' are being addressed.
>
> But you could overlay things ... [0405 files] with 'thunks'.
>
> So to allow a process (or the kernel) to have more than 64K, overlays can
> be loaded into memory and since the total physical space memory space is
> either 18 or 22 bits, if the kernel supports overlays - processes could get
> bigger [which is part of your first question].
> V7 was when 0405 [text only] overlays were added. With DEC's release of
> v7m - Fred Cantor rewrote the overlay code and they became more general
> [and that would go into 2.9BSD].
>
> So the programmer needs to decide what you wanted to put into what
> overlay. For processes, the kernel can swap out segments and replace them
> as needed. The key is that link needs to generate near/far style calls
> and it can be a PITA. If you want to access a routine that is not
> currently mapped into memory, the 'thunk' needs to ask the OS to switch it.
> Great thought of what was going to be stored where.
>
>
>
>
>>
>> The kernel could be compiled either with, or without separate I/D. The
>> only reason not to is if you didn't have more then 64k or were there other
>> reasons?
>>
> Well by V6, UNIX needed at least 64K of physical memory and it was really
> slow with anything less than 256K. For the kernel, using I/D allowed the
> kernel to grow more easily. By the time of trying to cram networking into
> it, running on anything less than an 11/44 was pretty hard.
>
> That said, Able made an alternate MMU called the ENABLE that allow 4M of
> memory on a Unibus system. It worked at a cache/bus repeater. So you set
> the internal MMU to point to it and then use its MMU. Very cool and a
> soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in
> Teklabs with the first Enable board.
>
> For whatever its worth, even with 4M the kernel had started to become a
> problem for V7 on an 11/70. Data buffers eat a lot of memory.
>
>>
>> So, besides the kernel what apps tended to be split? If I remember
>> correctly, vi was one, pascal another?
>>
> Anything that started to get big ;-)
>
> Ppeople ran out of data space and text space from 64K fairly fast. With
> the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away.
> Rob has an excellent paper -> "cat -v considered harmful" BSD UNIX, and
> the Vaxen greatly fueled that. Adding features and thinking less about
> what functionality was really needed started to get lost [so now we have
> Gnu - but I digress]. Werner and the BSD 2.9 folks are to be commended for
> what they did with so few resources. They moved things back from the Vax
> by using the overlays, but if you were to have any semblance of
> performance, you need the overlays to stay resident so you need that full
> 4M of memory.
>
> As for this specific question first two subsystems for the 11 that ran out
> of text space were indeed vi and Pascal subsystems (Joy having had his hand
> in both, BTW). But they were hardly the only ones once the genie was out
> of the bottle. Data space quickly became the real issue. People really
> wanted larger heaps in particular. In fact, by the 1990s, I knew of few
> programs that run out of 32-bit worth of text space, but many that
> started to run out of 32-bits of data space -> hence Alpha. But BTW:
> DEC took a performance hit originally, and there was a huge discussion at
> the time if 64-bits was really needed.
> ᐧ
>
[-- Attachment #2: Type: text/html, Size: 11229 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
2023-08-03 22:54 ` Clem Cole
2023-08-03 23:08 ` Dave Horsfall
2023-08-03 23:15 ` Clem Cole
@ 2023-08-04 0:38 ` John Cowan
2 siblings, 0 replies; 17+ messages in thread
From: John Cowan @ 2023-08-04 0:38 UTC (permalink / raw)
To: Clem Cole; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
On Thu, Aug 3, 2023 at 6:54 PM Clem Cole <clemc@ccc.com> wrote:
>
> ᐧ
> Adding features and thinking less about what functionality was really
> needed started to get lost [so now we have Gnu - but I digress].
>
And a Good Thing Too. I hate to think how many thousands of times in the
last few decades I have written "awk '{if (m < length) m = length} END
{print m}'" (and wondering for a moment if it's "length" or "len") until
someone mentioned "wc -L" to me just the other day. Arrgh.
[-- Attachment #2: Type: text/html, Size: 1572 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-08-04 21:41 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-03 21:48 [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread) Noel Chiappa
-- strict thread matches above, loose matches on Subject: below --
2023-08-04 21:40 Noel Chiappa
2023-08-03 23:14 Steve Simon
2023-08-03 23:10 Noel Chiappa
2023-08-03 23:42 ` Warner Losh
2023-07-30 23:59 [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman Erik E. Fair
2023-08-01 10:58 ` Erik E. Fair
2023-08-02 0:37 ` Dave Horsfall
2023-08-02 14:52 ` Ron Natalie
2023-08-02 21:14 ` Grant Taylor via TUHS
2023-08-02 22:20 ` segaloco via TUHS
2023-08-02 23:49 ` Rich Salz
2023-08-03 0:51 ` [TUHS] Re: python Larry McVoy
2023-08-03 2:07 ` Clem Cole
2023-08-03 16:57 ` [TUHS] Re: [TULSA] " Phil Budne
2023-08-03 17:00 ` Rich Salz
2023-08-03 20:35 ` [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Will Senn
2023-08-03 21:05 ` [TUHS] " Kenneth Goodwin
2023-08-03 21:10 ` Ronald Natalie
2023-08-03 21:16 ` Warner Losh
2023-08-03 21:24 ` Ronald Natalie
2023-08-03 22:34 ` Kenneth Goodwin
2023-08-03 21:05 ` Ronald Natalie
2023-08-03 21:44 ` Clem Cole
2023-08-03 22:08 ` Will Senn
2023-08-03 22:54 ` Clem Cole
2023-08-03 23:08 ` Dave Horsfall
2023-08-03 23:15 ` Clem Cole
2023-08-04 0:38 ` John Cowan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).