Re: [Simh] BLISS

2018-01-26 Thread Howard Bussey
SOAP was the assembler for the IBM 650.

—Howard

Sent from my iPhone

> On Jan 26, 2018, at 16:25, Larry Baker  wrote:
> 
> Was SOAP Knuth's assembler that optimized placement of the machine code on 
> the drum memory to minimize access latency for the next instruction?
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
>> On 26 Jan 2018, at 12:35:20 PM, simh-requ...@trailing-edge.com wrote:
>> 
>> The only other optimizing assembler I can think of is SOAP, way back in the 
>> 1950s.
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Recent build crashes on OSX

2016-02-17 Thread Howard Bussey
Googling “Process PTE …” shows this occurred before:

http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html

The suggestion was to try turning off optimization when compiling simh…

—Howard

> On Feb 17, 2016, at 2:48 PM, Michael Huff  wrote:
> 
> I grabbed simh_master.zip from github yesterday and compiled it on OSX and in 
> a virtualbox instance of Linux Mint 17. OSX is the native OS, Linux is in a 
> VM.
> 
> I have a 43BSD machine accessible to both on a shared drive. It will boot 
> normally when I run vax780 inside of the Linux VM, but  when I run the vax780 
> binary I compiled in OSX it crashes.
> 
> I'm assuming I should file a bug report on the OSX build? Should I post that 
> over at github and what do I need to include in the report?
> 
> I realize this is a very noob-ish mail, but I don't want to submit something 
> long and involved and find it's entirely irrelevant, so I'm asking here first.
> 
> if it helps, this is what the crash looks like:
> ---
> Michaels-iMac:43BSD michael$ uname -a
> Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 
> 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
> Michaels-iMac:43BSD michael$ !va
> vax780 boot.ini.default
> 
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 
> Process PTE in P0 or P1 space, PC: 8002B82F (XORW3 
> @-7035(R8),@D0FF6436,@-70B0(R1))
> sim> q
> Goodbye
> ---
> When I run that under my linux VM, I get:
> ---
> michael@michael-VirtualBox ~/simh/43BSD $ uname -a
> Linux michael-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 
> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> michael@michael-VirtualBox ~/simh/43BSD $ vax780 boot.ini.default
> 
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
>kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
> real mem  = 8388608
> SYSPTSIZE limits number of buffers to 140
> avail mem = 7187456
> using 140 buffers containing 524288 bytes of memory
> mcr0 at tr1
> mcr1 at tr2
> ---
> and it continues to the login prompt and acts normally.
> 
> Thank you for your time and advice.
> -Michael
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: On {O,D}DDT

2016-01-21 Thread Howard Bussey
The SDS-940 time sharing system had a DDT, which was the dynamic debugging 
tool. 4000;g started your program at 4000 octal. I believe both MIT and UC 
Berkeley worked on the implementation, so maybe the 940's DDT has roots in the 
MIT implementation for the PDP 1. 

[off topic, but SIMH includes a 940 simulator--] It is said that the 940 
time-sharing system was the first commercial OS to allow users with no special 
privileges to write and run assembly language programs. 

If "mother of all demos" means nothing to you, start at 
https://en.m.wikipedia.org/wiki/The_Mother_of_All_Demos. Regrettably, I knew 
nothing about that demo when I worked on the NBS/NOAA/DOC-B 940 in the '70s 
(with SIMH contributor Mark Emmer. 

--Howard

Sent from my iPhone

> On Jan 21, 2016, at 14:41, Hittner, David T (IS)  
> wrote:
> 
> That was awesome, Tim. Thanks for the historical perspective on the removed 
> pesticide disclaimer.  ;-)
>  
> And for certain systems, DDT was also the “DIBOL Debugging Tool”.
>  
> Dave
>  
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Timothe Litt
> Sent: Thursday, January 21, 2016 2:27 PM
> To: simh@trailing-edge.com
> Subject: EXT :Re: [Simh] On {O,D}DDT
>  
> On 21-Jan-16 11:53, Paul Koning wrote:
> 
>  
> On Jan 21, 2016, at 10:58 AM, Ethan Dicks  wrote:
>  
> On Wed, Jan 20, 2016 at 8:37 PM, Johnny Billquist  wrote:
> ODT actually stands for On-line Debugging Tool, not Online Debugging
> Technique.
>  
> I recall Octal Debugging Technique.  Anyone else remember that definition?
>  
> Things get interesting...
>  
> The name ODT was derived from the TOPS-10 debugger DDT -- an obvious name in 
> that era for something that gets rid of bugs, but officially it stood for 
> "Dynamic Debugging Technique".
>  
> ODT was much simpler, not offering symbolic debugging for one thing.  So it 
> got a different name, and since its I/O was pretty much just octal numbers, 
> replacing "dynamic" by "octal" made sense.
>  
> Then again, the DOS V9 manual says it's "On-line debugging technique".  So do 
> several RT11 manuals.  Hm.  Now I'm puzzled.  I clearly remember "octal" and 
> don't remember ever seeing "on-line".  And sure enough, the header of the 
> source code for RSTS "monitor ODT" (the kernel debugger) says "Octal 
> debugging tool".
>  
> So it looks like DEC wasn't consistent.  On-line in some places, octal in 
> others, and "technique" in the official documents I remember but "tool" at 
> least internally (a more obvious word to use, certainly).
>  
> paul
>  
>  
> Besides multiple technical writers, editors and product managers: there were 
> multiple implementations - including some for non-DEC machines.  I had a 
> small part in DDT-11, and also implemented an ODT-clone on 8 and 16-bit uPs.  
> ODT was, IIRC originally called Octal Debugging Technique, in a nod to DDT.   
>  Actually, there are two DDT-11s; one that runs on the -11 (used in ANF-10 
> network nodes), and one that lives on a -10 (or -20) and remotely debugs the 
> -11, and/or the 11's crash dumps.  In fact, DDT-11 can be booted in exec mode 
> on a KS10, and run PDP-11 diagnostics under simulation against real hardware. 
>  (Yes, I did that.)
> 
> Of course, DDT was also an octal debugger (unless you changed the input or 
> output radix) - and more capabie as it could deal with symbol tables, paging, 
> and so forth.  But ODT was only capable of debugging in octal.  (A 
> consequence of the PDP-11's 4KW minimal and 28K maximum memory size.)  So 
> that's what it was called.  Someone in marketing decided that octal was too 
> geeky, and that 'on-line' would sell better.  
> 
> Engineers being what we are (many students of human, as well as computer 
> languages), pointed out that "technique" is how one uses a tool.  But it's a 
> stretch to call a tool a technique, at least in ordinary usage.  So 'tool' 
> was floated, but by that time ran against the couple of decades of 
> established culture.  (A very long time in technology-years.)
> 
> An early DDT manual (~ 1970, but I've lost the colophon page) explains the 
> DDT situation thusly:
> 
> INTRODUCTION
> DDT-10 (for Dynamic Debugging Technique) *  long page
> 
> In very small print, smaller than I can reproduce here:
> *Historical footnote: DDT was developed at MIT for the PDP-1 computer in 
> 1961.  At that time DDT stood for "DEC Debugging Tape".  Since then, the idea 
> of an on-line debugging program has propagated thoroughout the computer 
> industry.  DDT programs are now available for all DEC computers.  Since media 
> other than tape are now frequently used, the more descriptive name "Dynamic 
> Debugging Technique" has been adopted, retaining the DDT acronym.  Confusion 
> between DDT-10 and another well-known pesticide, 
> dichloro-diphenyl-trichloroethane (C14H9Cl5) should be minimal since each 
> attacks a different, and apparently mutually exclusie, class of bugs.
> 
> Oddly enough, this paragraph subsequently caught the a