test-drb December 2020

test-drb@ccmp.vtda.org

103 participants
82 discussions

Heathkit H89A (was accidentally circuit cellar...)

by shumaker＠att.net

Thanks!?? No clue which of us were first but if the museum is interested, I will pass. Steve Shumaker On 11/30/2020 12:42 PM, Tom Uban via cctech wrote: > Valparaiso, IN. > On 11/29/20 4:21 PM, s shumaker via cctalk wrote: >> where are you? >> >> Steve >> >> >> On 11/29/2020 9:37 AM, Tom Uban via cctalk wrote: >>> I'm sorting through my stuff and have Heathkit H89A computer. Last time I messed (20 years ago) it >>> showed signs of life, but was not fully functional. I do have a manual for it. >>> Pics upon request. >>> Any interest? >>> >>> --tom >>> >>>

3 years, 4 months

VMS on x86-64/ARM/RISC-V? - was Re: Microvax 3100 VMS 7.3 password reset

by camiel.vanderhoeven＠vmssoftware.com

On 11/14/20, 1:49 AM, "cctech on behalf of Adam Thornton via cctech" <cctech-bounces at classiccmp.org on behalf of cctech at classiccmp.org> wrote: > I mean obviously the NEXT thing to do is start bugging VSI for ARM support?given that the OS runs on VAX, Alpha, Itanic, and x86_64, how much really crucial and hard-to-port assembly can be left in it??and given the way datacenters are trending, it might not even be a commercially stupid move. I want to run VMS on my phone (or my next Mac). Doesn?t everyone? Hi Adam, Possible architectures beyond x86 we're keeping an eye on are ARM and RISC-V, but they'll need to start doing a lot better in the datacenter before it'll be worth our while. So far, ARM in the datacenter hasn't taken off the way many predicted it would. One thing I'm better at than crystal ball gazing though, is I can give you an idea of how much hard-to-port assembly is left, since I wrote most of the x86 assembly code in it :-) With the port to x86, we made a conscious effort to minimize the amount of code written in assembly; so at this point, it's pretty much limited to code where (a) we can't use the stack, or we need to manipulate the stack pointer in a non-standard way; (b) we need to use a special instruction that we don't have a compiler builtin for (these are mostly cases where an instruction is only used in one place); and (c) code that needs to mix calling standards - i.e. the code shims necessary to interact with the UEFI firmeware. Category (a) is obviously the more interesting one, and that includes things like code that is responsible for switching between VMS' four modes (kernel, executive, supervisor, and user mode), and context switching for the schedulers (OS scheduler, kernel process scheduler, and POSIX threads scheduler). The OS scheduler is a good example of our effort to eliminate assembly code. On VAX, Alpha, and Itanium, the scheduler loop and the idle loop (which performs maintenance tasks such as dirty page zeroing) were written in assembly, and re-written with each port. For x86, I rewrote these in C, using small assembly helper routines only in the critical parts where it couldn't be avoided. In total, there are 30 modules that were written in x86-64 assembly. I'd classify 10 of those are trivial, 16 as average, and 4 as complicated and difficult. The complicated and difficult category contains code responsible for dispatching system services, handling interrupts and exceptions, delivering ASTs. As much design and work was involved in those assembly modules though, a whole lot of x86-specific work was done for the MACRO-32 compiler. MACRO-32 originated as the VAX assembler, and while it is a compiler on other architectures, it is still much like an assembler, and specific translations from the VAX instruction set to the target architecture need to be made. The MACRO-32 compiler talks to the LLVM code generator backend at a lower, more instruction-centric level than the compilers for higher languages, and this work is very x86-64 specific. Given that about 1/3 of the OS is written in MACRO-32, we won't get rid of MACRO-32 code in the OS any time soon. (The other 2/3rds are written in BLISS and C) Also, in the C, Bliss, and MACRO-32 code, lots of conditionalizations are made on architecture. Certain things are done differently on Alpha than they are on Itanium, and on x86 we sometimes do things the way we did them on Alpha, sometimes the way we did them on Itanium, and sometimes we need to come up with an x86-specific way. So, the port to x86 has made a future port to ARM or RISC-V easier; particularly by moving to the LLVM code generator backend, and by figuring out how to run a four-mode OS on a two-mode architecture without sacrificing the benefits of running in four modes; but it has by no means made it trivial. Camiel

3 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb December 2020