On 5/1/16 04:10, Erik Baigar wrote:
> sorry, but there emerged more questions from my side ;-) It's a trip down memory lane ;) > > On Fri, 29 Apr 2016, Christian Kennedy wrote: > >> Hawk, but not the odd S/140 and MV/8000 punches) and software (ARTS, >> ARTS/32) were ROLM designs. > > I only know ARTS from ads being sold on eBay - this is some > form od Ada development environment (or a complete OS?)? The > acronym probably means something like "Ada Real Time System" (?). Advanced Real Time System. Memory resident with hard latency limits for servicing interrupts; it had nothing to do with the Ada compiler. > > Was this a cross compiler tool or did it run natively on the > hardware? As there is a /32 variant, do you think a variant > for the 16 bit machines like 16xx or MSE14 did survive some- > where? ARTS/32 was for Eagle architecture machines and actually made use of the rings :P. Prior to the Hawk there was a punch (basically a militarization of DG's prints) of the MV/8000 of which something like three were sold; it was about the size of a large modern refrigerator and was sufficiently massive that it had large lifting rings on the top of the cabinet; while sometime someone would fire up the one that lurked in the hardware lab, 99.999% of ARTS/32 (and all of the Marvin) development took place on commercial DG hardware -- MV/8000s for ARTS/32, MV/10000s for Marvin (with MV/4000s used as target machines). I have no idea if any of the software survived anywhere :( It's funny that you mention the MSE14; it was the other punch done by ROLM, basically a S140 stuffed into a 1/2 ATR chassis. IIRC it had a somewhat painful gestation, because mapping the 15x15" S/140 processor onto multiple smaller cards created interesting timing problems. The ADA compiler was developed in partnership with Rational; as part of that deal ROLM was supposed to look at creating a militarized version of the R1000. The R1000 was freaking huge -- much taller than a MV/8000, to the point that getting it into the machine room was a bit of a challenge -- and it turned out it was markedly slower executing Ada code than a MV/8000 running code produced by the ROLM compiler, so in the end that project went more or less nowhere. > >> Steve Wallach had incorporated into the PTE format for the Eagle in >> order to turn memory references into I/O requests that would be >> transparently resolved in the physical memory of another machine. > > Although I do not recognize the "PTE format", I guess the Eagle > project is related to a widely sold US made aircraft, right? This > one carried at least one Hawk/32 ;-) PTE ::= Page Table Entry. "Eagle" was DG's name for the MV architecture; ROLM's "Hawk" was a play on "Eagle" ;) > > Some of the Rolm stuff I have got is from the company which serviced > the equipment of the ATTAS aircraft... > > http://www.dlr.de/dlr/desktopdefault.aspx/tabid-10644#gallery/1751 > > http://www.dlr.de/dlr/Portaldata/1/Resources/documents/ATTAS_Handout_2001.pdf Huh. Interesting :) >> deal from each other ("Yes, I know that the PATU instruction only occurs >> twice in the body of AOS/VS, but it's executed on every context switch >> and as such it's probably not a really good idea to implement it by >> having the microcode scrub each entry in the TLB"). > > I guess you have not been happy with context switching and how > the Rolm microcode implemented it. IIRC we caught the problem early enough that they were able to come up with a hardware invalidation that did materially what the MV's did and thus we didn't end up paying a terrible performance penalty on context switching. > Unfortunately, there is nothing > on the internet related to the instruction set of the Hawk/32 > family but the hardware contained lot of big custom chips and > therefor I guess it was far more powerful and complex than > e.g. the Eclipse or earlier machines. It's instruction set is identical to the MV/8000, but there's some differences in how it treats "undefined" results and "undefined" bitfields in a handful of instructions, enough to require tweaking the diagnostics. -- Christian Kennedy, Ph.D. ch...@mainecoon.com AF6AP | DB00000692 | PG00029419 http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration…"
