Is it a lost cause?

I find that hard to believe, but perhaps it's true. I'll ask the guys who are restoring a 2966.

I never used VME/B. I did use VME/K for three years, until we dumped it for a home grown operating system.

--
Using UNIX since v6 (1975)... 

Use the BIG mirror service in the UK: 
 Click to see the full signature
Reply to
Bob Eager
Loading thread data ...

--
"The great thing about Glasgow is that if there's a nuclear attack it'll  
look exactly the same afterwards." 
 Click to see the full signature
Reply to
The Natural Philosopher

Wow, they were more like a thousand when I was buying them for use with MP/M machines, which would have been a few years earlier than SCO Unix (or even SCO XENIX which came first).

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

In 1991, the Wyse 60 cost $295 from Paradise Computers (according to an ad in PC Mag of March 16, 1991).

Reply to
Raymond Wiker
[ snippage ]

Of possible interest may be RISC-V, which is being developed as a "free and open architecture" - specifications available to implement gratis by industry as well as academia etc; with both commercial and open source implementations available:

formatting link

Quoting from there, because they describe it better than I can:

" Why RISC-V? Our goals in defining RISC-V include:

  • A completely open ISA that is freely available to academia and industry.

  • A real ISA suitable for direct native hardware implementation, not just simulation or binary translation.

  • An ISA that avoids ?over-architecting? for a particular microarchitecture style (e.g., microcoded, in-order, decoupled, out-of-order) or implementation technology (e.g., full-custom, ASIC, FPGA), but which allows efficient implementation in any of these.

  • An ISA separated into a small base integer ISA, usable by itself as a base for customized accelerators or for educational purposes, and optional standard extensions, to support general-purpose software development.

  • Support for the revised 2008 IEEE-754 floating-point standard.

  • An ISA supporting extensive user-level ISA extensions and specialized variants.

  • 32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations.

  • An ISA with support for highly-parallel multicore or manycore implementations, including heterogeneous multiprocessors.

  • Optional variable-length instructions to both expand available instruction encoding space and to support an optional dense instruction encoding for improved performance, static code size, and energy efficiency.

  • A fully virtualizable ISA to ease hypervisor development.

  • An ISA that simplifies experiments with new supervisor-level and hypervisor-level ISA designs.

What?s Available?

Right now, you can download the final user-level ISA specification, a draft compressed ISA specification, a draft privileged ISA specification, and a suite of RISC-V software tools including a GNU/GCC software tool chain, GNU/GDB debugger, an LLVM compiler, a Spike ISA simulator, QEMU, and a verification suite.

To sample the architecture without installing anything, try out ANGEL, a JavaScript ISA simulator that boots an interactive session of riscv-linux on a simulated RISC-V machine in your browser.

You can also visit the UC Berkeley Architecture Research projects page to see a number of RISC-V based projects including a high-performance, energy-efficient Rocket processor (a 64-bit RISC-V single-issue in-order core), suitable for both high-speed simulation and full synthesis, is available for download. "

One open-source SOC implementation in progress:

formatting link

The Rocket implementation mentioned above that allows generating Verilog of various chip configurations, including FPGA-synthesizable ones:

formatting link

// Christian

Reply to
Christian Brunschen

I think at that time am entry level PC/ST with screen and keyboard was

its about that today. Maybe a little less. Of course its a far BETTER PC :-)

In general the Wyse was about the same as a color monitor.

Was the Wyse 50 cheaper?

I do remember that the chief reasons for a PC was that ethernet and telnet clients made the whole deal cheaper than serial cables everywhere

- and faster too.

But you needed the DOS licenses ;-(

--
Future generations will wonder in bemused amazement that the early  
twenty-first century?s developed world went into hysterical panic over a  
 Click to see the full signature
Reply to
The Natural Philosopher

Wyse terminals were much much cheaper No disk drive for a start

--
Microsoft : the best reason to go to Linux that ever existed.
Reply to
The Natural Philosopher

On z/Series, the stack and heap come from the same pool. The limit is on total storage used, not one limit for heap, another for stack as found on unix type systems.

So, you can use up all the storage with malloc, but eventually fail on a stack request.

(At least in theory.)

--
Dan Espen
Reply to
Dan Espen

Linux, and many flavors of Unix, install inaccessible guard pages on either side of the stack to prevent inadvertent corruption.

Software could catch the SIGSEGV and manually extend the stack if memory was available. The original bourne shell used that trick to extend the heap on the PDP-11

formatting link

Reply to
Scott Lurndal

siginfo.si_addr gives the VA of the address that wasn't present. It's simple to check if it is in certain bounds, and recover appropriately. BTDT.

See also:

formatting link

Reply to
Scott Lurndal

With a 64-bit virtual address space, you're more likely to run out of backing space (swap) than the VA space itself.

Reply to
Scott Lurndal

The stack and heap come from the same pool on most systems. The stack grows down, the heap grows up.

But if you run out, you run out. There are guard pages on the stack, so you can catch that situation if it ever happens. Frankly, with that much stack available, only a very poorly written program is going to hit the limit.

--
Using UNIX since v6 (1975)... 

Use the BIG mirror service in the UK: 
 Click to see the full signature
Reply to
Bob Eager

Indeed. I thought I'd said '32 bit' in there but I obviously forgot!

--
Using UNIX since v6 (1975)... 

Use the BIG mirror service in the UK: 
 Click to see the full signature
Reply to
Bob Eager

Yep, was there. In 1987 we had a cardinal rule that every price transaction was to pass through all systems and be delivered to all recipients within 300 milliseconds. This was a hard limit. Exchange to close if we couldn't cope.

300 ms is evidently the lower limit of the human reaction time that can bring oscillations into such machine-human loop.

So this was audited.

We also were to not have any prioritisation among recipients, randomly selecting distribution order without bias. This was also audited.

So, we not only had a real-time system, we had another real-time system to audit the first one, and a third one to match the first one for correctness.

-- mrr

Reply to
Morten Reistad

Fifty terminals on a KA-10? The one we had at Yale was pretty busy with a dozen.

On the other hand, software system design counted for a lot. At Dartmouth, they had a GE 635, about the same size as a KA-10, and a Datanet 30 or two to handle the low level TTY stuff, and they ran 50 users with great performance. Internally it was more like a transaction system, with the TTYs all talking to one big monitor job for the usual editing stuff, and you only got your own process when you typed RUN. Contrary to rumor, DTSS was not BASIC-only (although their BASIC was better than anyone else's.) It had the usual set of languages and you could write in assembler if you wanted.

Reply to
John Levine

Depended on the language. Fortran didn't allow recursion, so each routine had a single static save area it used for all its calls. PL/I had both recursion and variable sized arrays, so it allocated a chunk of storage used more like a conventional stack.

Reply to
John Levine

And over delay lines.

Reply to
John Levine

It has a linkage stack, used by some specialized call and return instructions. The linkage stack is complex enough that I never figured out all the details, but it was largely to enable programs to span multiple 31-bit address spaces back on the 32 bit systems.

Z has it because it has nearly everything its predecessors did, but with the address space limits gone, the motivation for the linkage stack is now just backward compatibility.

Reply to
John Levine

... and Williams Tube memory

formatting link

Reply to
Christian Brunschen

migration from real memory os/360 to MVS involved giving each task/applications outside the kernel its own 16mbyte virtual address space. However, os/360 is extremely pointer passing intensive paradigm so they included an 8mbyte kernel image in every 16mbyte virtual address space (so kernel calls could easily continue with pointer passing ... and kernel code simply address parameters&returns like it always had).

Problem was that a lot of subsystems (outside the kernel) also got their own 16mbyte virtual address spaces ... and also required pointer passing API. This required creating a "COMMON SEGMENT", 1mbyte area mapped into every 16mbyte application virtual address space ... where global space was allocated for parameter & return passing between applications and subsystems (running in their own address space). However, the amount of common space was somewhat proportional to system size, number of concurrent applications and concurrent subsystems. In late 370 days ... before 31bit and 370-xa, on large systems, the common areas were threatening to grow to 8mbytes ... leaving nothing for applications (8mbyte kernel image plust 8mbyte common area out of 16mbyte virtual address space left nothing for applications).

For 370/xa both "access registers" and program call/return were defined for subsystems. Early simple implementation, application made a kernel call to transfer to subsystem. Kernel would load application address space pointer into secondary address space (access) register, load the subsystem virtual address space into primary virtual/home address space register and invoke the subsystem (passing the calling routines registers). Subsystems could use special instructions to retrieve/store data in the calling application virtual address space. Program call/return would reference a hardware defined table that had pointer for every valid subsystem and its virtual address space pointer. An application could call a subsystem, where the program call did the address space pointer changes all in hardware (w/o requiring a kernel call). Similarly a subsystem could make a program return ... which reverse the virtual address space pointer changes .... back to the calling application virtual address space.

Applications could now efficiently call a routine that exists in different address space ... which had authorization to fetch/store the calling application virtual address space (w/o requiring pathlength through the kernel).

There has since been some use of access registers for use to define "dataspaces" ... effectively a virtual address space that was all data ... with application using "access registers" to access the data in different virtual address space. However, the original purpose of access registers was for a subsystem in its own address space to access passed parameters in the calling application address space (and store return values).

--
virtualization experience starting Jan1968, online at home since Mar1970
Reply to
Anne & Lynn Wheeler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.