| Re: mainframe I/O, was CR or LF? [message #395442 is a reply to message #395438] |
Fri, 05 June 2020 15:26   |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Friday, June 5, 2020 at 12:46:15 PM UTC-6, Questor wrote:
> Also, I suspect there are still PDP-11s in active use.
Not counting systems in operation in the hands of collectors or in museums, I
think I did hear of at least *one* PDP-11 still being used for something recently.
John Savard
|
|
|
|
| Re: mainframe I/O, was CR or LF? [message #395443 is a reply to message #395442] |
Fri, 05 June 2020 16:28 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Friday, June 5, 2020 at 12:46:15 PM UTC-6, Questor wrote:
>
>> Also, I suspect there are still PDP-11s in active use.
>
> Not counting systems in operation in the hands of collectors or in museums, I
> think I did hear of at least *one* PDP-11 still being used for something recently.
>
Some may be in use in imbedded systems. Some Xerox printers (maybe 4090) I
believe used the LSI-11 as a processor. I expect some of these are still
in use. Nice solid and usable computers.
--
Pete
|
|
|
|
| Re: CR or LF? [message #395444 is a reply to message #394824] |
Fri, 05 June 2020 16:22 |
Jan van den Broek
Messages: 70
Registered: April 2012
Karma: 0
|
Member |
|
|
Fri, 22 May 2020 17:09:20 -0700 (PDT)
fred_weigel@hotmail.com schrieb:
> On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote:
[Schnipp]
>> images are not ASCII text with end of line markers.
>
> Oddly, Gareth, a lot of images are exactly that. When base64 encoded,
> or otherwise transmitted. Its only when interpreted by a web browser
> that they become... images.=20
Netpbm
Postscript
SVG
--
Jan van den Broek
balglaas@xs4all.nl
Frisbeeterianism: n. The belief that when one dies, one's soul gets
stuck on the roof.
|
|
|
|
| Re: memory sizes, mainframe I/O, was CR or LF? [message #395445 is a reply to message #395426] |
Fri, 05 June 2020 16:29 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Dan Espen <dan1espen@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> John Levine <johnl@taugh.com> writes:
>>>> > In article <1h8CG.525299$TM6.280020@fx42.iad>,
>>>> > Scott Lurndal <slp53@pacbell.net> wrote:
>>>> >>> I think making the page size only 512 bytes was a big mistake and wasn't forward
>>>> >>> looking, given the trends of increasingly larger and increasingly less expensive
>>>> >>> memory.
>>>> >>
>>>> >> Although in the late 70's, I'm not sure how evident that trend was...
>>>> >
>>>> > 4K DRAM chips appeared in 1973, 16K DRAM chips in 1974, and chip
>>>> > densities were doubling every year or two.
>>>> >
>>>> > IBM's S/370 in the early 1970s had both 2K and 4K pages. The 512 byte
>>>> > VAX pages were obviously too small at the time.
>>>>
>>>> I wonder if they wanted the size of the page to match the basic
>>>> disk sector size; perhaps to avoid checkerboarding when managing
>>>> the working set (another, hmmm, interesting VMS feature).
>>>
>>> Makes sense.
>>>
>>> By going down to 512 they drastically increase the odds that they can
>>> page things out that they never have to page in again.
>>>
>>> When I worked on S/360 I always wondered how many 4K pages I had where I
>>> only really accessed one byte with any frequency.
>>>
>>> The OS has to keep some kind of map, each real page is mapped to some
>>> address space/real address. It's been too long since I read POPs on
>>> this but assuming each 512 virtual bytes needs 2 addresses to track it,
>>> that's only an overhead of 8 bytes for every 512 virtual bytes.
>>
>> Page tables are interesting beasts. Generally there are slightly more
>> than four bytes per page (in a 32-bit architecture, eight bytes in 64-bit)
>> of page table overhead (most page tables are tree structures three or four
>> levels deep - some support final entries at higher levels in the tree
>> which provides larger page sizes (e.g. intel x86-64 supports 4k, 2M and 1G
>> pages, ARM64 has three basic 'granule' sizes, 4k, 16k and 64k, and by
>> terminating the lookup at higher levels, supports two or three larger block
>> sizes per each of the granule sizes).
>>
>> Then you have the hardware virtualization solutions, where the page tables
>> are nested (the guest page table physical addresses are in turn translated
>> by another set of hypervisor page tables into real physical addresses). For
>> performance, you need a bunch of TLBs, since a single table walk in the
>> nested case, where both levels used 4k pages, requires 23 memory accesses;
>> can be reduced to 11 using 1GB pages on the hypervisor side.
>>
>
> VM/370 has handshaking, I guess it’s called paravirtualization, where the
> guest hands off all paging to the hypervisor, eliminating half the
> overhead. I don’t know what x86 hypervisors do.
Paravirtualization is what x86/amd hypervisors did, prior to 2012 when AMD
added nested paging hardware support. Paravirt page tables are horribly inefficient
by comparison to hardware solutions.
|
|
|
|
| Re: PDP-11s, was mainframe I/O, was CR or LF? [message #395454 is a reply to message #395442] |
Fri, 05 June 2020 20:08 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <1f44135d-1f65-46ee-9eb1-04da797b5935o@googlegroups.com>,
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Friday, June 5, 2020 at 12:46:15 PM UTC-6, Questor wrote:
>
>> Also, I suspect there are still PDP-11s in active use.
>
> Not counting systems in operation in the hands of collectors or in museums, I
> think I did hear of at least *one* PDP-11 still being used for something recently.
DEC stopped making PDP-11s in 1997 and their licensee Mentec stopped
shortly after that so anything with a PDP-11 in it must be at least 20
years old.
--
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: mainframe I/O, was CR or LF? [message #395542 is a reply to message #395443] |
Sun, 07 June 2020 21:03 |
|
|
Originally posted by: David Lesher
Peter Flass <peter_flass@yahoo.com> writes:
> Some may be in use in imbedded systems. Some Xerox printers (maybe 4090) I
> believe used the LSI-11 as a processor. I expect some of these are still
> in use. Nice solid and usable computers.
I know of some in CAD mills, but they are too shaken by years of vibration
to be reliable.
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
|
|
|
|
| Re: CR or LF? [message #398286 is a reply to message #393271] |
Sat, 22 August 2020 14:15 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Sunday, April 12, 2020 at 7:00:17 AM UTC-4, Gareth Evans wrote:
> Both CR and LF are command characters that reflect the
> mechanical make-up of some printing devices, the
> ASR / KSR 33 / 35 perhaps being the most common at
> the time of the creation of the code.
>
> But where there are those who argue that device
> characteristics should be hidden away in the
> device drivers and not be embedded in printable
> text, should not the end of a line be marked by ETX
> and the end of a file by EOT and not ^Z?
Teletypewriters were developed for written communications,
not as computer terminals. The adaption for computer
service came later. There was no such thing as
"device drivers".
Teletypes originally used the 5-bit Baudot code. It
did not have the luxury of many control characters.
Indeed, many teletypes were tape printers, not page
printers. Western Union printed on a tape which
was pasted to a blank. This made for a simpler
mechanism-- no carriage, need for return, linefeed,
or page eject. It saved on characters, too as the
CR and LF could be used for other purposes,
important with a limited set.
|
|
|
|
| Re: CR or LF? [message #398287 is a reply to message #393300] |
Sat, 22 August 2020 14:18 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Monday, April 13, 2020 at 1:11:42 AM UTC-4, Quadibloc wrote:
> It is certainly true that, on the System/360 time-sharing system that I used
> first, on ASCII terminals, one pressed the carriage return key, and not the line
> feed key, to end a line, because it was certain to be present, and when both
> were present, it was usually larger or more conveniently placed.
When time sharing came along, different systems had different
protocols for the user to signal end-of-line and the computer
to indicate it was ready for the next line. A common one
was the user hit CR and the system responded with LF when
ready. But not always, sometimes the opposite, sometimes
x-on and x-off were utilized to facilitate paper tape
input.
|
|
|
|
| Re: CR or LF? [message #398300 is a reply to message #398286] |
Sat, 22 August 2020 21:55 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, August 23, 2020 at 4:15:36 AM UTC+10, h.......@bbs.cpcn.com wrote:
> On Sunday, April 12, 2020 at 7:00:17 AM UTC-4, Gareth Evans wrote:
>> Both CR and LF are command characters that reflect the
>> mechanical make-up of some printing devices, the
>> ASR / KSR 33 / 35 perhaps being the most common at
>> the time of the creation of the code.
>>
>> But where there are those who argue that device
>> characteristics should be hidden away in the
>> device drivers and not be embedded in printable
>> text, should not the end of a line be marked by ETX
>> and the end of a file by EOT and not ^Z?
>
> Teletypewriters were developed for written communications,
> not as computer terminals.
That's right. Teleprinters were in use for that purpose in the 1920s.
> The adaption for computer
> service came later. There was no such thing as
> "device drivers".
>
> Teletypes originally used the 5-bit Baudot code. It
> did not have the luxury of many control characters.
>
> Indeed, many teletypes were tape printers, not page
> printers. Western Union printed on a tape which
> was pasted to a blank. This made for a simpler
> mechanism-- no carriage, need for return, linefeed,
> or page eject. It saved on characters, too as the
> CR and LF could be used for other purposes,
> important with a limited set.
|
|
|
|
Members
Search
Help
Register
Login
Home
