Asymmetric multiprocessing...

Nagging hardware related question? Post here!
User avatar
Pr0f
Gold Card
Posts: 391
Joined: Thu Oct 12, 2017 9:54 am

Re: Asymmetric multiprocessing...

Postby Pr0f » Mon Jun 03, 2019 1:01 pm

This shared RAM idea could be a good way of separating out mundane hardware control from the main CPU and it's jobs workload, allowing offloading of a lot of the I/O tasks

Taking the idea of the IPC interface and growing out to something much bigger and extensible ?


User avatar
1024MAK
Super Gold Card
Posts: 544
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Asymmetric multiprocessing...

Postby 1024MAK » Mon Jun 03, 2019 3:21 pm

I don’t think there will be very much interest in this subject unless some software is developed that makes good use of the concept - a killer app so to speak. But anyway...

Nasta wrote:The documentation clearly shows that the Acorn Tube is designed around using the BBC operating system, and this extends down to the very hardware, which is tailored to pass parameters the way OS calls do it. How this is relevant to a machine that runs an entirely different OS with a completely different abstraction of it's operations and methods of parameter passing, is beyond me.


I think you may have completely missed the point. Yes of course all the documentation is specific to the Acorn BBC B / Master OS. Because the Tube is an Acorn system. That does not mean that it can’t be used on other systems.

On a Acorn BBC B or Master 128 system, the original computer is used to provide all I/O including keyboard, display system and mass storage. The system as designed by Acorn loads all code and data for the parasite from mass storage (floppy or hard disk or equivalent) into the the parasite. This software can be anything you like. It does not have to conform to any standards other than the memory map. The host does not have to use a Acorn BBC like system. Again, even on a BBC B or a Master, you can load and run any software you like. The game Elite on the BBC B does exactly this. It ignores the documented Acorn OS/Tube system software and does its own thing.

As you say, anything that wants to make use of an additional processor will need both new software running on the host QL and on the parasite.

So if you use say dual port RAM to provide the communications between the host and a parasite, or any other communication system, software will be required to be written for both the QL host and the parasite. Obviously the QL code will be 68K code. The code for the parasite will again obviously have to be code for whatever MPU/CPU is chosen. So that is a lot of development required. Even if the chosen MPU/CPU is a 68K device.

But if we were to make use of the Tube system, and could develop some suitable code that would run on a QL to provide the minimum functionality needed to get the Tube protocol working, then a lot of the existing software that runs on a Tube second processor would run fine.

At the end of the day, the Acorn system is just a command set. If the QL side software can receive, decode and then carry out the request, the code running in the parasite will not know that it is not connected to an Acorn system.

Are you really telling me that you don’t think the QL could print or draw to the display in response to some simple command codes, “scan” the keyboard and send the resulting data back to the parasite, or transfer data from/to an attached floppy disk drive to/from the parasite in response to a request from the parasite?

Now, to preempt the next question, would such a system be QL like? No. Because what the system feels like depends on what is actually running on the parasite. If the parasite is a Z80 CPU (or Z80 like environment) and you are running CP/M, then it will look and feel like a CP/M system. If the parasite is a 80186 or similar CPU, and you are running MSDOS, then it will look and feel like a MSDOS system.

We would not be limited to being ‘locked in’ to the Acorn Tube protocol, as I say above, the hardware can be used beyond the Acorn system software protocol. In this regard, the development time and requirements are similar to using dual port RAM.

Next question, how useful would a “second processor” system be? Well, it very much depends on what people would want to do with it. To be honest, I can’t see many here in the QL community being very interested. If you want a faster, better QL system, there are various other ways to do that. Gold card, SuperGold card, and the newer QL compatible systems etc. etc.

I only brought the idea up, as a possible quicker way to achieve the objective of attaching a faster non 68K CPU to a QL.

Mark


QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
User avatar
1024MAK
Super Gold Card
Posts: 544
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Asymmetric multiprocessing...

Postby 1024MAK » Mon Jun 03, 2019 3:38 pm

So, just out of interest, what term or name do the QL community use to describe the original Sinclair QL which after all already has two processors as standard (the main 68008 and the IPC/Intel 8049 microcontroller)?

If an intelligent internet interface system is added, it would then have three processors.

Would continuing to off-load I/O operations be a more practical way to proceed? Maybe develop a new HDMI like display system based on a R-Pi?

The logical conclusion being the main 68K processor not being in direct control of any I/O system.

Thoughts?

Mark


QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
qlspence
ROM Dongle
Posts: 2
Joined: Tue May 28, 2019 4:34 pm

Re: Asymmetric multiprocessing...

Postby qlspence » Mon Jun 03, 2019 4:35 pm

Maybe I'm being selfish but one of the things that the QL would really benefit from with all original chips and no super gold card would be one or more co-processors which is constrained to the 64k area where original mode 4/8 screen data is. This would allow some incredibly useful graphical effects. Failing that, an area of upper memory which would allow for small routines to read from one area of data and write to another. Would also be helpful to have interrupts so that the 68k8 can at least mask to know when various conditions have occurred on the co-processor(s), but not essential as I could probably work it out with timing, co-processor type depending of course.


User avatar
Dave
SandySuperQDave
Posts: 2420
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Asymmetric multiprocessing...

Postby Dave » Mon Jun 03, 2019 4:43 pm

If we think of the tube as a sci-fi portal, it would be a tiny crack in a wall under a bridge somewhere. By comparison, DP SRAM is like a bus driving through a tunnel. If you need to get lots of passengers moved sequentially you'd take the bus over that shady portal under the bridge any day ;)

One clarification... I've used the terms "symmetric" and "asymmetric" do divide between "same CPU" and "different CPU" architectures. I have read others use it differently, and to consider the divide to be whether the CPU runs the same single OS image, or different code.

So, in more mainstream terms what I am describing is MPP, or Massively Parallel Processing.

Obviously, given the nature of QDOS' jobs system, QDOS would be a much easier OS to adapt to an MPP architecture than most other monolithic OS.

The main flaw in what I have described is that although there is a good parent<>child communication system, ALL transfers between CPUs have to go through the parent CPU. There's no "private bus" between the child CPUs. I would like to remedy this, but haven't thought of a way to do so yet.


User avatar
Dave
SandySuperQDave
Posts: 2420
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Asymmetric multiprocessing...

Postby Dave » Mon Jun 03, 2019 5:05 pm

1024MAK wrote:So, just out of interest, what term or name do the QL community use to describe the original Sinclair QL which after all already has two processors as standard (the main 68008 and the IPC/Intel 8049 microcontroller)?


To be fair, the IPC and 8049 can not be reprogrammed by the system, cannot run user programs, and work only as Intelligent Peripheral Controllers in the early 80s meaning of IPC. It's just a state machine and something running a loop.


Nasta
Gold Card
Posts: 337
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Asymmetric multiprocessing...

Postby Nasta » Mon Jun 03, 2019 7:25 pm

1024MAK wrote:I don’t think there will be very much interest in this subject unless some software is developed that makes good use of the concept - a killer app so to speak. But anyway...

Nasta wrote:The documentation clearly shows that the Acorn Tube is designed around using the BBC operating system, and this extends down to the very hardware, which is tailored to pass parameters the way OS calls do it. How this is relevant to a machine that runs an entirely different OS with a completely different abstraction of it's operations and methods of parameter passing, is beyond me.


I think you may have completely missed the point. Yes of course all the documentation is specific to the Acorn BBC B / Master OS. Because the Tube is an Acorn system. That does not mean that it can’t be used on other systems.


...as long as they basically look like a BBC computer.
Note, again, that the entire Tube HARDWARE specification is based on how the BBC OS does things. To a 68k computer this is rather restrictive.
Yes, it could do the same things the BBC does, in effect, emulate it's OS calls (most of them as some specific things like video modes and sound are not the same or supported on the QL) but my question is, why would you want a QL to do this in effect to run BBC parasite software. Yes - it gets all it's code via the host, but a certain host side interface is expected for it to run, which would then have to be re-written for the QL, in essence making it a BBC emulator of sorts.
It should also be noted that the actual hardware is an Acorn ULA which is actually situated in the parasite hardware 'box' and only addressed via the BBC side port as a couple of memory locations. This is not too difficult to do on a QL (almost trivial) but again, what would be the actual concrete benefit?
The BBC has this benefit since the Tube system and extra CPUs on the BBC have been around for decades so there are applications that can use them to good effect.

On the QL some form of multiprocessing has been implemented with the IPC - and it's not that uncommon, many retro computers have a second CPU to control the keyboard (mostly on the keyboard PCB itself).
I think what the thread was aimed at are applications that take various types of load away from the main CPU and delegate. It's mostly an IO thing, though it can be further extended. For instance, on 68k machines the original FPU unit is a dedicated processing unit that works in parallel with the main CPU, reason being that some FP operations take hundreds of cycles, during which the main CPU can do other things like service interrupts. To your point, this sort of thing can be used for emulation, but in general it's expected of the host to be able to support most of the operation set needed to exploit a more advanced second CPU. Given a Rasberry PI, it is actually more logical for the Pi to be a host for a QL system rather than the other way around, the reason why it works on the BBC is the PI is used to emulate other processors.
That being said, given how cheap processing on the level of a PI has become, it is also possible to use a RPI as an IO platform for other systems, including the QL. This is not about a killer application, but rather a killer OS integration. In an asymmetric processing situation, the extra CPUs do not execute applications (at least not directly).

The QL is a relatively minimalistic system that can never the less support (or, better said, does not prevent the support of) some rather fancy concepts in computing. One of it's strengths is an attempt to provide a relatively uniform abstraction of various IO operations. In this sort of model there is nothing preventing the OS calls to be only a data (structure) passing mechanism to some more or less specialized hardware that does the actual work, quite possibly using one or more extra processing 'units' of some sort. The question is, if your processing units are capable of many things, how can you interface them to your host system and be able to exploit their advantages without setting any major limitation when deciding how the OS interfaces with said units. DPRAM is one of the better methods, since it can be used to set up many kinds of data structures to communicate between the main CPU and extra processing unit, and it's main limitations are basically size and the need to set up complex signaling protocols in software on both sides. Using these principles for IO operations is just one of the more obvious exploits as the point where the application passes control to an IO abstraction and back, is already well defined in the OS.

This already goes in in any QL system with a mass storage device that is, or is based on a PC hard drive. All of these have a uC on them tat takes care of a lot of the low level stuff, while the actual host interface communicates on a much higher level of abstraction. For instance, an IDE hard drive uses a register file and buffer RAM to transfer data - the file holds parameters for the data transfer and a command/status register, which are visible to both the host and the uC on the hard drive. When the parameters are set (and data loaded if needed) a command is written into the command register (which is a trigger for the uC on the device), at which point the uC takes over, reads the parameters from the registers, controls actual hardware, and uses or gets the data if required using the RAM buffer - which is a sort of large mail box for the data, while the registers are smaller ones for the parameters. In this case the operating protocol is such that true dual port access is not strictly required, but it could just as well be implemented as dual port RAM.
With proper hardware, the device on 'the other side' (this side being the host computer) could also have it's operating code loaded by the host, which would, again with the right provisions, enable the host to define what the device is supposed to do. In a typical IO system this is typically not the case in normal operation, but in cases such as add-on DSPs or graphics processors, it's almost a rule. There are many ways such a system can be set up, in some cases the lines can get blurred (no reason why a second CPU of the same kind as the main one could not be used for such tasks), but the main point is that this is transparent on the level of applications programming, except in cases where an OS resource is actually provided by a specialized processing unit which has not been built into the system for some reason (such as not having an FPU).


User avatar
1024MAK
Super Gold Card
Posts: 544
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Asymmetric multiprocessing...

Postby 1024MAK » Mon Jun 03, 2019 10:08 pm

@Nasta

I have never said that a system using dual port RAM should not be considered. In fact shared memory systems have been around for a long time. They just used very careful control and timing as years ago dual port RAM was very expensive. Various 1980s computers either use shared memory for IO devices (e.g. screen), or have a number of registers to transfer data to/from a specialist IO chip (you gave the example of an IDE PATA HDD, but there are plenty of others including sound chips, video display processors), and there are also DMA or Blitter chips that can either pause the CPU, steal some CPU cycles, then return control, or only work when the CPU does not need access to RAM. Yet other systems use the split bus concept.

Everything has advantages and disadvantages. If time, money and resources are almost unlimited, yes, we would like as near a prefect system as we could get. But rarely do we have that situation. Hence compromises have to be made. Sinclair itself made countless compromises in its designs of its products.

As for you saying that a Tube system for the QL would have to be like a BBC computer. Do you think a CP/M application or a MSDOS application knows about the BBC specific video modes or the BBC specific sound system?

When the QL is running a terminal program that is emulating say a VT52 or VT100, is that not a similar concept? Same for QL applications that were produced to allow access to the Prestel service or for accessing Bulletin Boards.

If any kind of multiple processor system is developed for the QL and QL compatibles, would the protocols also support QL and QL compatible specific hardware? And if you are going to build in some future proofing how far would you go?

It’s funny that you should go on and talk about abstractions. For the U.K. 8 bit home computers, the Acorn BBC range kept the ‘language’ such as BASIC separate from the OS, hence it was possible to port BBC BASIC to other systems. And it was easy to produce other programming languages for the Acorn BBC range despite Acorn making improvements to the OS over time. Because of the abstractions, if software used the official vectors, compatibility was maintained. The QL of course was developed later, so could improve things further.

Mark


QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
User avatar
1024MAK
Super Gold Card
Posts: 544
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Asymmetric multiprocessing...

Postby 1024MAK » Mon Jun 03, 2019 10:34 pm

Dave wrote:
1024MAK wrote:So, just out of interest, what term or name do the QL community use to describe the original Sinclair QL which after all already has two processors as standard (the main 68008 and the IPC/Intel 8049 microcontroller)?


To be fair, the IPC and 8049 can not be reprogrammed by the system, cannot run user programs, and work only as Intelligent Peripheral Controllers in the early 80s meaning of IPC. It's just a state machine and something running a loop.

Well, Sinclair describes the QL as having two processors...
ECC4AE1A-D303-4F81-B07A-D5BAF8AF276F.jpeg
Two processors


In specialist systems, there may not be a way for the main CPU system to be reprogrammed, and they cannot run any new user programs. But they are still considered to be or contain processors. E.g. in industrial systems you will find racks with processor cards with 68K CPUs running fixed application programs, the ‘user’ can only change the configuration by requesting new data ROMs from the manufacturer with the new requirements as supplied to the manufacturer. Only the data ROMs are changed. The ROM with the fixed application program is not disturbed or changed.

The main limitations are the technology of the day. Microcontrollers of today are rather more advanced compared to the 1980s. Today, a replacement for the IPC could well be designed to be reprogrammed by the main system CPU.

Hence, if more IO duties are devolved to microcontrollers or other MPUs , there is no reason why if required, they could do other things. Some arcade machines used multiple MPUs. Some had a MPU responsible for the sound system for example.

So would an improved sound system with its own MPU or microcontroller in charge of one or more sound generator chips be something that members would be interested in?

Mark


QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)

Who is online

Users browsing this forum: No registered users and 10 guests