Concurrent TI Pascal and Real-time Exec

[+FarmerPotato]

 

In my idle phone-only time this weekend, I’ve been reading about concurrency in the TI books: Microprocessor Pascal Users Manual (MP351)  and anything I can find on the standalone Real-time Executive (or the Pascal RTS.) Reading on a very small screen. (And typing now!)

 

The Bedford UK Microprocessor group published TI’s Software Development Handbook (which I’d never seen until the TI Archive at Southern Methodist U in Dallas TX.) The 1981 2nd edition is in Archive.org and Bitsavers , with much more discussion of concurrency (chapters 5-6.) 

 

It’s remarkable for its advocacy of structured programming.  In particular, the hierarchy of SYSTEM, Program, Processes (Threads) and subroutines. 

 

But it was the era of textbooks by Niklaus Wirth— and Edsgar Dijkstra, with whom TI in Texas associated closely. I bet they  hired his graduate students from UT Austin where their Data Systems group was located. (Textbooks cited in every Bibliography in these books!) 

 

@Stuart, your 990 website indicates that you have a copy of MP385 the MP Pascal System Manual. Is there any way you could share that? (Is it MP305 or MP385?) I bet it has much more detail on the Real-time API than the Pascal Users Guide. 

there was also a (lost to time?) Component Software Handbook and TI Realtime Executive manual. Targeted at small systems like the TM990 boards with 16K of RAM. 

 

Each manual above says that the Real-time Executive, and the Pascal RTS, provided semaphores, concurrent process priorities, scheduling, and interrupts. Plus shared memory, where shared queues—think mailboxes—are located for IPC (interprocess communication.)

 

 

They built Mutex (see Pascal Users Manual) on Counting Semaphore (“the most useful kind of semaphore” heh heh.) I Compare and contrast Unix v6, which is built on spinlock and sleeplock. (Source found on internet particularly the teeny v6_riscv)

 

So it has Counting Semaphores, with atomic operations Wait/Signal, queues for waiting, and global Ready queue. There is a simple priority scheduler, which I’m unclear how it interacts with time slices, as it’s principle is that the highest priority process that is Ready gets all the CPU. Maybe these were separate implementations?

 

The Real-time rules are simple. The Ready queue is sorted by priority at all times.  If a process WAITs on a semaphore whose count is 0, then it goes to the tail of the semaphore’s Wait queue. Then the scheduler runs the next process at the head of the Ready queue. Otherwise it continues running. 

 

If a process SIGNALs a semaphore, and there is a  process in that semaphore’s Wait queue, both go to the Ready queue, where the scheduler decides which one gets the CPU (highest priority.) otherwise it increments Count and  continues to run. 

 

 

The WAIT and SIGNAL *must* be atomic—they are system calls (XOP 15) and LIMI 0. 

 

An example, Make Tea, does a WAIT on a semaphore Kettle_Boiling, then pours the water and DELAYs for five minutes. Presumably, other lower priority processes are allowed to run, like Set Table or Sweep Kitchen. 

 

A bigger example is a Mailbox circular buffer, where 2 processes produce or consume Mails. At start, the semaphore Slot_Available is initialized to count 10, the total free slots for mail. A semaphore Mail_Ready is initialized to Count  0.

 

The processes look like this:

Producer

DO

WAIT(slot_available)

SIGNAL(mail_ready)

REPEAT 

 

Consumer

DO

WAIT(mail_ready)

SIGNAL(slot_available)

REPEAT

 

I’ve worked out one way to code these concurrency features as these TI books present them. (On my iphone, Working Copy is a very nice code editor and git client! Makes good use of the small screen and miserable  touch keyboard.) 

 

Like TI says, It uses an XOP for the atomics WAIT and SIGNAL, during which interrupts are disabled. The XOPs test Counts, manipulate queues, then either RTWP to the caller, or save R13-R15 to process record then BLWP into the Scheduler. 

 

But I’d like to see the full API to clarify decisions TI made. 

 

 For example, in the disassembled Make Tea program, it kicks off with the Start Process call, which  takes 5 stack parameters. It gets arguments of   1 and  a stack size 6. And 3 other parameters -1,0,0. In Stop process the stack is given that “1” variable again like it’s a Pricess ID. I’m not sure what that 1 might accomplish. Perhaps the program is pre-loaded with a PID in that memory location? 

 

Also, the Pascal translator makes position independent code! Very Nice. How?

 

On entry, the Pascal program has registers initialized with a stack pointer, code segment pointer (all branch statements are indexed relative to this!) and a data segment pointer for its local variables. The binary comes with a header, starting with relative entry point, and max  stack size required. 

 

I enjoy researching all this!

 

 

In my day job, everything is multiprocessor and threaded, so it’s fun to see this simple but adequate model where Pascal accomplishes everything with counting semaphores. 

 

In 1981, TI (or at least the MP folks in Bedford) was going in the direction of multiprocessing on 9900s (see E-Bus Systems Guide.) 

 

I’ve read @apersson850 posts on his multitasking UCSD/P-Code. Very good to read. Though setting up p-code at home is daunting. (Also I’m not at home!)

 

Ideally,  I’d like to find the source to TI’s pascal RTS or RE semaphore implementation. Or at least a bona-fide ROM or disk copy to disassemble! Any leads on this? @jbdigriz

 

 

 

 

 

[apersson850]

In the UCSD p-system, there are special p-codes for SIGNAL and WAIT. The p-codes are atomic.

The description of the concurrent Pascal you wrote above is pretty much identical to what the p-system does on the TI 99/4A. A full implementation of concurrency in p-systems should also support ATTACH. The 99/4A doesn't.

ATTACH is used to tie a semaphore to some kind of "hardware" event. I put it in quotes since the hardware could be something that's detected by software when serving the normal VDP interrupt in a 99/4A. But it could be a real hardware interrupt in architectures allowing that.

 

With attach, it's for example possible to allow a process to wait for a character on a serial port, a key to be pressed or whatever is going on in the particular computer. I realized, after trying to extend the p-system in the 99/4A with pre-emptive multitasking, that it would probably be better to extend it with support for ATTACH instead. That's fully doable, since index tables for instructions and intrinsics are in RAM during execution.

The pre-emptive multitasking almost works, but fails somewhere in unit HEAPOPS. That made it uninteresting to continue with that attempt.

Implementing ATTACH I would like to try, if I can make up the time for it...

 

In the multitasking support unit I wrote I also implemented monitors.

Edited March 16, 2022 by apersson850

[apersson850]

This post was in error, and now I can't get rid of it again.

Edited March 16, 2022 by apersson850

[jbdigriz]

On 3/14/2022 at 1:30 PM, FarmerPotato said:

 

In my idle phone-only time this weekend, I’ve been reading about concurrency in the TI books: Microprocessor Pascal Users Manual (MP351)  and anything I can find on the standalone Real-time Executive (or the Pascal RTS.) Reading on a very small screen. (And typing now!)

 

The Bedford UK Microprocessor group published TI’s Software Development Handbook (which I’d never seen until the TI Archive at Southern Methodist U in Dallas TX.) The 1981 2nd edition is in Archive.org and Bitsavers , with much more discussion of concurrency (chapters 5-6.) 

 

It’s remarkable for its advocacy of structured programming.  In particular, the hierarchy of SYSTEM, Program, Processes (Threads) and subroutines. 

 

But it was the era of textbooks by Niklaus Wirth— and Edsgar Dijkstra, with whom TI in Texas associated closely. I bet they  hired his graduate students from UT Austin where their Data Systems group was located. (Textbooks cited in every Bibliography in these books!) 

 

@Stuart, your 990 website indicates that you have a copy of MP385 the MP Pascal System Manual. Is there any way you could share that? (Is it MP305 or MP385?) I bet it has much more detail on the Real-time API than the Pascal Users Guide. 

there was also a (lost to time?) Component Software Handbook and TI Realtime Executive manual. Targeted at small systems like the TM990 boards with 16K of RAM. 

 

Each manual above says that the Real-time Executive, and the Pascal RTS, provided semaphores, concurrent process priorities, scheduling, and interrupts. Plus shared memory, where shared queues—think mailboxes—are located for IPC (interprocess communication.)

 

 

They built Mutex (see Pascal Users Manual) on Counting Semaphore (“the most useful kind of semaphore” heh heh.) I Compare and contrast Unix v6, which is built on spinlock and sleeplock. (Source found on internet particularly the teeny v6_riscv)

 

So it has Counting Semaphores, with atomic operations Wait/Signal, queues for waiting, and global Ready queue. There is a simple priority scheduler, which I’m unclear how it interacts with time slices, as it’s principle is that the highest priority process that is Ready gets all the CPU. Maybe these were separate implementations?

 

The Real-time rules are simple. The Ready queue is sorted by priority at all times.  If a process WAITs on a semaphore whose count is 0, then it goes to the tail of the semaphore’s Wait queue. Then the scheduler runs the next process at the head of the Ready queue. Otherwise it continues running. 

 

If a process SIGNALs a semaphore, and there is a  process in that semaphore’s Wait queue, both go to the Ready queue, where the scheduler decides which one gets the CPU (highest priority.) otherwise it increments Count and  continues to run. 

 

 

The WAIT and SIGNAL *must* be atomic—they are system calls (XOP 15) and LIMI 0. 

 

An example, Make Tea, does a WAIT on a semaphore Kettle_Boiling, then pours the water and DELAYs for five minutes. Presumably, other lower priority processes are allowed to run, like Set Table or Sweep Kitchen. 

 

A bigger example is a Mailbox circular buffer, where 2 processes produce or consume Mails. At start, the semaphore Slot_Available is initialized to count 10, the total free slots for mail. A semaphore Mail_Ready is initialized to Count  0.

 

The processes look like this:

Producer

DO

WAIT(slot_available)

SIGNAL(mail_ready)

REPEAT 

 

Consumer

DO

WAIT(mail_ready)

SIGNAL(slot_available)

REPEAT

 

I’ve worked out one way to code these concurrency features as these TI books present them. (On my iphone, Working Copy is a very nice code editor and git client! Makes good use of the small screen and miserable  touch keyboard.) 

 

Like TI says, It uses an XOP for the atomics WAIT and SIGNAL, during which interrupts are disabled. The XOPs test Counts, manipulate queues, then either RTWP to the caller, or save R13-R15 to process record then BLWP into the Scheduler. 

 

But I’d like to see the full API to clarify decisions TI made. 

 

 For example, in the disassembled Make Tea program, it kicks off with the Start Process call, which  takes 5 stack parameters. It gets arguments of   1 and  a stack size 6. And 3 other parameters -1,0,0. In Stop process the stack is given that “1” variable again like it’s a Pricess ID. I’m not sure what that 1 might accomplish. Perhaps the program is pre-loaded with a PID in that memory location? 

 

Also, the Pascal translator makes position independent code! Very Nice. How?

 

On entry, the Pascal program has registers initialized with a stack pointer, code segment pointer (all branch statements are indexed relative to this!) and a data segment pointer for its local variables. The binary comes with a header, starting with relative entry point, and max  stack size required. 

 

I enjoy researching all this!

 

 

In my day job, everything is multiprocessor and threaded, so it’s fun to see this simple but adequate model where Pascal accomplishes everything with counting semaphores. 

 

In 1981, TI (or at least the MP folks in Bedford) was going in the direction of multiprocessing on 9900s (see E-Bus Systems Guide.) 

 

I’ve read @apersson850 posts on his multitasking UCSD/P-Code. Very good to read. Though setting up p-code at home is daunting. (Also I’m not at home!)

 

Ideally,  I’d like to find the source to TI’s pascal RTS or RE semaphore implementation. Or at least a bona-fide ROM or disk copy to disassemble! Any leads on this? @jbdigriz

 

 

 

 

 

Not immediately. At one point, TI was really big on Pascal, and yes they did hire a lot of Austin graduates. 990 mini customers wanted COBOL, COBOL, and COBOL, though. So the interest waned, at least for business systems. That's what I've been told, anyway. I'll see if I can find out more, though. With the TM990 systems, that may have been different, and UCSD-Psystem was available on those as well. I'd be interested in reading that MP385 manual also. The TM990's were sold as development systems and in industrial production systems, often embedded. I'm guessing Siemens ended up with those, mostly. That may be a good place to dig, or at some of the automation houses. Power Basic and Forth seem to have been used widely with the TM990's. PS. a lot of 13 TM990 docs sold a week or so ago on Ebay. Hopefully whoever got them will see that they're scanned in and posted somewhere, if they're not already on Stuart's site or bitsavers. https://www.ebay.com/itm/363747274951  I should be buying this stuff, like I should have bid on those /1s the other day, and a number of other things, but I'm barely scraping by month-to-month as it is.

[+FarmerPotato]

Hey @jbdigriz don’t feel bad about those TM990 data sheets, they’re mine now.
 

I did not see them on Archive.org.  But they are not too exciting, as some are redundant slices of other manuals. Some are Application Reports, mostly sample code. 
 

The TM990/306 Speech Evaluation Module manual was what I wanted. The 306 was reported in several news magazine articles (in a nearby thread.) The 306 came out just as TI made the 0285 or 5100 available to customers. 
 

 

 

 

The 306 manual was kind of a bust. It doesn’t have schematics, and the block diagram .. takes liberties. I was hoping to see how TI interfaced EPROM to the speech chip, but I can still guess.  The manual does list the vocabulary. It has words like Pico. 
 

Compared to the 306 book, and only seen on my visit to TI Archives at SMU, the Speech Education Module manual was a treasure. TMS70C40 based SBC with FORTH.   Full schematics, parts list, assembly and FORTH source. And almighty googles finds a single forum post from someone who stashed a TI sample decades ago, but hasn’t reported running it or scanning the book. 
 

 

Anyhow I’ll get the TM990 booklets scanned to Bitsavers quality. Except those darn 3-hole punches. Received a new scanner. (Documate got dropped, non funzione.) 

 

 

 

 

[+FarmerPotato]

Oh, the lot included a TM990 card cage manual. It has a lot of material on the 3 variations 4,8,12 slot.)  But I think it’s redundant with some  scans I had read before. Pinouts, schematic, termination, recommended loads, I think I’ve seen online. 

[jbdigriz]

7 hours ago, FarmerPotato said:

Hey @jbdigriz don’t feel bad about those TM990 data sheets, they’re mine now.
 

I did not see them on Archive.org.  But they are not too exciting, as some are redundant slices of other manuals. Some are Application Reports, mostly sample code. 
 

The TM990/306 Speech Evaluation Module manual was what I wanted. The 306 was reported in several news magazine articles (in a nearby thread.) The 306 came out just as TI made the 0285 or 5100 available to customers. 
 

 

 

 

The 306 manual was kind of a bust. It doesn’t have schematics, and the block diagram .. takes liberties. I was hoping to see how TI interfaced EPROM to the speech chip, but I can still guess.  The manual does list the vocabulary. It has words like Pico. 
 

Compared to the 306 book, and only seen on my visit to TI Archives at SMU, the Speech Education Module manual was a treasure. TMS70C40 based SBC with FORTH.   Full schematics, parts list, assembly and FORTH source. And almighty googles finds a single forum post from someone who stashed a TI sample decades ago, but hasn’t reported running it or scanning the book. 
 

 

Anyhow I’ll get the TM990 booklets scanned to Bitsavers quality. Except those darn 3-hole punches. Received a new scanner. (Documate got dropped, non funzione.) 

 

 

 

 

Awesome!

[jbdigriz]

7 hours ago, FarmerPotato said:

Oh, the lot included a TM990 card cage manual. It has a lot of material on the 3 variations 4,8,12 slot.)  But I think it’s redundant with some  scans I had read before. Pinouts, schematic, termination, recommended loads, I think I’ve seen online. 

I don't think the manuals online cover the 12-slot, but I'd have to look back over them. It wouldn't hurt to scan this one in as well. Outstanding that you're doing all this. Thanks!

[+FarmerPotato]

28 minutes ago, jbdigriz said:

I don't think the manuals online cover the 12-slot, but I'd have to look back over them. It wouldn't hurt to scan this one in as well. Outstanding that you're doing all this. Thanks!

Sorry, 16 slot! The TM990/510,520,530. 

[apersson850]

I did an extension for machine control to my pre-emptive system for multitasking Pascal with the 99/4A. That extension was similar to what you could accomplish with a working ATTACH in Pascal, provided you could attach it to the desired event. At the VDP interrupt, my assembly language code, wedged into the system's interrupt service, checked some hardware inputs and could then control some semaphores directly. The net effect what that I could write code in high-level Pascal, code that acted like it was started by a hardware interrupt. That interrupt was simulated by assembly software, but from Pascal level you couldn't tell the difference.