Do you mean the "fancy lights" or "fancy null job"? I don't know how you include it in RSTS V10 during SYSGEN. It used to be that you could answer "Y/L" to the question asking if you wanted to build a new monitor. If that doesn't work, editing SYSGEN.COM to mention "LIGHTS" as an additional symbol to search for during the link step of RSTS should do the trick. paul DEFORG LIGHTS .SBTTL A FANCY NULL JOB ; NEEDED DEFINITIONS SISDR0 = 172200 ;SUPERVISOR INSTRUCTION DESC REG 0 SISAR0 = 172240 ;SUPERVISOR INSTRUCTION ADDR REG 0 PS = 177776 ;PROCESSOR STATUS ORG NULJOB ; INITIAL ENTRY POINT NULJOB: BIT #004000,@#PS ;DO WE HAVE SUPERVISOR MODE (2 REG SETS)? BNE 30$ ;YES, DO IT FANCY... ; THE SIMPLE NULL JOB 10$: MOV R2,R1 ;RELOAD THE WAIT COUNTER 20$: WAIT ;DISPLAY THE LIGHTS (R0) A WHILE SOB R1,20$ ;KEEP WAITING ROL R0 ;ELSE SHIFT PATTERN 1 PLACE LEFT BR 10$ ; AND AROUND AGAIN... ; FANCY NULL JOB SETUP 30$: MOV #176000,R3 ;PRE-SET THE MEM ADR LIGHT PATTERN MOV (PC)+,R4 ;GET DESC REG VALUE FOR .BYTE 4!2,128.-1 ; R/W AND 4K MOV #SISDR0,R5 ;POINT TO SUPERVISOR DESC REGS MOV R4,(R5)+ ;LOAD SISDR0 WITH 4K AND R/W MOV R4,(R5)+ ;LOAD SISDR1 WITH 4K AND R/W MOV R4,(R5)+ ;LOAD SISDR2 WITH 4K AND R/W MOV R4,(R5)+ ;LOAD SISDR3 WITH 4K AND R/W MOV #177600,SISAR0-SISDR0(R5) ;LOAD PAR4 FOR THE I/O PAGE MOV R4,(R5)+ ;LOAD SISDR4 WITH 4K AND R/W MOV #40$,R1 ;FORM A MMU ADDRESS ASH #-6,R1 ; THAT WILL MAP OUR CODE BIC #^C<001777>,R1 ; IN SUPERVISOR MODE MOV R1,SISAR0-SISDR0(R5) ;LOAD MMU ADDRESS FOR PAR5 (CODE) MOV (PC)+,(R5)+ ;LOAD SISDR5 WITH .BYTE 2,128.-1 ; R-O AND 4K CLR (R5)+ ;LOAD SISDR6 WITH "ABORT" MOV R4,(R5)+ ;LOAD SISDR7 WITH 4K AND R/W MOV #000340,@#PS ;;;WE CAN'T AFFORD AN INTERRUPT HERE MOV #054040,-(SP) ;;;NEW PS OF SUPERVISOR MODE @ PR1 MOV #40$,-(SP) ;;;NEW PC OF OUR ROUTINE BIC #^C<77>,(SP) ;;; CORRECTED FOR RUNNING BIS #120000,(SP) ;;; OUT OF PAR5 RTI ;;;DROP INTO SUPERVISOR MODE!!! ; THE FANCY NULL JOB 40$: MOV R3,R1 ;COPY PATTERN FOR MEM ADR LIGHTS BIC #^C<077776>,R1 ; AND ENSURE AN HONEST ADDRESS CLR R4 ;CLEAR A HIGH ORDER MOV R1,R5 ; AND SET LOW ORDER AS ADDRESS ASHC #3,R4 ;EXTRACT THE APR # ASL R4 ; AND FORM APR # TIMES 2 ADD #SISAR0-160000+100000,R4 ;FIND PAR TO USE (I/O PAGE = PAR4) ASH #-3,R5 ;CORRECT THE VIRTUAL ADDRESS BIC #^C<017700>,R5 ; AND ISOLATE OFFSET WITHIN PAR NEG R5 ;SUBTRACT OFFSET WITHIN PAR ADD #70$,R5 ; FROM OUR WORK TABLE ASH #-6,R5 ;FIND THAT AS A MMU ADDRESS BIC #^C<001777>,R5 ; WITH NO SIGN EXTENSION MOV R5,(R4) ;LOAD CORRECT PAR WITH CORRECT ADDRESS BIT R4,#16 ;ARE WE USING PAR0? BNE 50$ ;NO ADD #20,R4 ;YES, CORRECT FOR PAR7 NEXT 50$: SUB #200,R5 ;GO BACKWARDS 4K MOV R5,-(R4) ; AND LOAD NEXT LOWER PAR WITH THAT MOV (PC)+,(R1) ;LOAD THE RETURN INSTRUCTION JMP (R4) ; WHICH IS JUMP THROUGH R4 MOV (PC)+,-(R1) ;LOAD THE WAITING INSTRUCTION WAIT ; WHICH IS WAIT MOV R2,R5 ;REFRESH WAIT COUNTER MOV PC,R4 ;SET THE RETURN ADDRESS CMP (R4)+,(R4)+ ; FOR WAITING DONE (PIC) 60$: JMP (R1) ;GO OFF AND DISPLAY LIGHTS... SOB R5,60$ ;DO UNTIL TIME'S UP ASL R0 ;SHIFT LIGHTS 1 PLACE LEFT ROR R3 ; AND BACK THROUGH MEMORY LIGHTS ADC R0 ; WITH A CARRY BR 40$ ;FROM THE TOP... .BLKB 100 ;RESERVE WORK SPACE 70$: .BLKB 100 ;RESERVE WORK SPACE .END

I misunderstood. Here it is, from the first chunk of system probing code. ; THE BR BELOW MUST BE AT AN ADDRESS WITH 3 LOW DIGITS ZERO. . = <.-SATBUF+777+4>&177000+SATBUF-4 ;ROUND TO 4 BELOW DESIRED BOUNDARY CHK1160:CLR @#CPUERR ;WRITE TO CPU ERROR REGISTER .IIF NE <.-SATBUF>&777, .ERROR ;MICROCODE BUG DETECTOR REQUIRES THIS BR NO1160 ;DIDN'T SKIP, ALL IS WELL MESSAG ;SOME 11/60'S HAVE A PROBLEM HERE ... .ASCII "This PDP-11/60 is missing the following ECO's:"<200> .ASCIZ " Module M7872: ECO #7 Module M7873: ECO #6"<200><12> UNORG COMB (R5) ;DISALLOW WRITING TO THE REGISTER That's interesting. It says the bug isn't simply doing a skip that isn't supposed to happen -- it implies that the skip only happens if the PC after the instruction is a multiple of 512. Wow. Re condition codes: it depends a bit on how you define them. There is an interesting scheme used in the Electrologica machines (X1 from 1958, X8 from 1964). Similar to ARM, they allow essentially all instructions to be executed conditionally. Unlike ARM, you get to choose which instructions set the condition flag and whether to set it on zero or negative or something more complicated that I always forget. Then you can conditionally execute instructions (if flag set, or if flag clear). You can have intervening instructions that don't touch the flag. For example: A=VAR1,P " Load register A with VAR1, remember if it was positive SUBC(:SUB42) " Call SUB42 to get a value in S Y,S+VAR2 " Add VAR2 if VAR1 was positive N,S-VAR3 " but subtract VAR3 from S The subroutine call saves and restores (by convention, you can avoid it) the flag. That's a little different from PDP-11 condition codes but it's close enough I think. The older machines I know do CDC or PDP-10 style "branch conditionally on the contents of a register" rather than condition codes. paul

In ARM, yes. There, as far as I remember (which isn't far) condition codes are set by most instructions, as on the PDP-11. The extra bit of magic Electrologica offered was to control which instructions touch the condition flag, so you could set it and then do a whole bunch of stuff on that condition, with operations interspersed that don't check the condition. The example I just gave is a very simple case, with two instructions conditionally executed from that one flag setting (with opposite sense); real code may show longer strings. The conditional execution modifier (the leading Y, or N,) had a third option: "U," meaning "do the operation including flag setting but don't actually write the result". So you didn't need separate test instructions; any instruction could become a test-flavor instruction by being U-modified. For example "U,RCA(1),P" (rotate A right one bit circularly) is a non-destructive "test if the contents of A is even. paul

On 2/7/22 15:10, Thomas DeBellis wrote: PDP-8 works this way too. Many people wrinkle their noses about it, but I find the skip model to be very convenient and easy to wrangle. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 2022-02-07 21:41, Dennis Boone wrote: I don't agree. Skips aren't really any more strange than branches. We're talking assembler here anyway. There are bound to be jumps all over the place always. Not really more spagetti in any architecture compared to any other. The probably more "ugly" thing in the PDP-8 is that you do self modifying code very often. With the limited instruction set of the PDP-8, only one accumlator, and very limited addressing modes, combining any instruction with an ISZ (increment, basically) of that instruction allowed it to walk over some memory space easily, since the address is in the low 7 bits of the instruction. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2022-02-08 00:12, Dennis Boone wrote: Wait... Why are you comparing to HLLs? That's not a meaningful comparison. The alternative are actually conditional jumps. Which isn't much different than conditional skips. The biggest difference is the lack of flexible targets for the conditional skip. Which really aren't making it any more spagetti. But sure, compared to high level languages all assembler is spagetti. Skips or not. Indeed, which is why I seriously questioned the claim that skips would make code more spagetti. It don't really directly affect multi-tasking, but it does affect reentrancy, which is commonly desired in multitasking, yes (but not absolutely required). But yes, that, and recursion isn't really possible without more proper local storage, of which a stack is the most convenient and common form. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2022-02-08 00:15, Thomas DeBellis wrote: Well, branches are definitely important. But computers do a lot of just moving data around as well. Which sometimes is one of those times when the condition codes helps. If you want to move until some condition, you might be lucky that this condition can be easily detected without any extra instructions. Such as moving something until you hit a NUL... :-) Yup. On the PDP-11 condition codes for both signed and unsigned conditions are generated all the time, so it becomes a question of just picking the right type of conditional branch. Yeah. That's always one of those annoying things. Another way is to mask out the interesting bits and compare to the expected value. But it's additional instructions anyway. The problem exists in the same way on the PDP-11. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2022-02-08 09:34, dave.g4ugm(a)gmail.com wrote: The technology is fairly common today. Speculative execution after branches, branch predictions based on history or statistics. All rather interesting stuff. I seem to remember even seeing machines that speculatively executed down both paths, and just discarded the wrong one once it knew. This is also a reason for the kind of conditional execution of instructions Paul was mentioning (with regards to ARM and others). Having that kind of capability in the CPU reduces the amount and need of branches. (Don't help with loops though, those still need to use branches.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

It's funny you should mention the CDC 6600 because it was in this context that the branch remark was made. We spent /a lot/ of time studying the 6600 because of all the interesting ideas to be found there (like register score boarding, Etc.)  It was while we were discuss arithmetic performance that he pointed out the branch percentages.  What he was doing was trying force us to look at things at a systemic level instead of thinking math and he said what said not so much for accuracy but for effect. PDP-10 hackers of KA and KI vintage will immediately recognize the CDC instruction buffer as something like it was used.  The PDP-10 had sixteen registers (called accumulators or AC's) and these aliased the first sixteen locations of memory, giving you some real flexibility in instruction usage. When you /really/ needed to get speedy, you would put your instructions into the AC's and jump in.  The core memory of the day was at microsecond speeds and needed cycle time.  AC's were operating sub-microsecond time (0.21) and needed no cycle time.  So you could win pretty big. Another thing to do was to take advantage of Tops-10 giving priority to jobs with smaller memory requirements.  When WACCC (WPI) TECO had to write a file, it completely destroyed its code image (the high segment) to execute in a little AC loop to write the buffers out.  We undergraduates thought it was a very fine hack. None of this mattered on the KL because of the cache memory speed.

It's worth pointing out that the PDP-10 _does_ have PC flags and instructions to test them (just check my domain name!) but they're not used for things like zero/negative tests. There is a carry flag of sorts (the APR overflow bit) but it was almost never used. With 36 bits you didn't worry much about overflows :) Bob

... and the KL had double precision integer math instructions (DADD, DSUB, DMUL, DDIV) as well as double word integer MOVEs, so you could get 72 bit integer arithmetic without needing to deal directly with the carry flag anyway. I can't remember about the KI - I think it had DMOVE, but not any of the arithmetic instructions. As a practical matter the PC flags were not very useful to the average user mode programmer. And JFCL, with no flag bit specified, was the traditional NOP. I believe on a KL something like TRNN was actually faster to execute, but by then nobody was willing to switch. Bob

On the KI the fact that it did not have the KL instructions was no real problem as they all trapped and you could emulate them in the monitor.... Almost, the KI thinks a ADJBP is a increment byte pointer, so here you need to bring out your wire_wrap tools and add checking for the AC field. -P ----- Original Message -----

I finally gave up and looked at my orange book (decsystem10 assembly language handbook), 3^rd edition. You are correct; the KI had DMOVE, DMOVEM, DMOVN to handle double floating point.  The KI does not have \ double integer arithmetic. As a matter of fact, the DMOVN only works for floating point format; using it to negate the double integer format does the wrong thing.  I forgot about that once and couldn't understand why my code wasn't working...