Status of Zap

So I take it no one is decided to update !Zap yet?

You could always offer to help… I believe that the request was for volunteers.

You could always offer to help… I believe that the request was for volunteers.

I would volunteer [muggins (at) svrsig (dot) org] to help in updating Zap because I use it a lot, but would need some guidance.

I’ve just used ARMalyser/ObjAsm on the Zap module.

Two XOS_HeapSort need updating.
SWP to be changed – (ref one of the updates on this site).

Perhaps switching off – one or two of the interupts around a replacement SWP.

Non portable instruction -
|process_key_command|
  STMFD R13!,{R1,R13,R14} ; CAUTION: Unpredictable – base register in list and write back.
  ANDS R14,R2,#&F000000
  BEQ     %F00
  CMP     R14,#&3000000
  STRCC   R0,[R13,#4]
  ADDCC   R0,R13,#4
00
  MOV     R1,#1
  BL      |process_command|
  LDMFD   R13!,{R1,R14,PC}
  B |process_command| ;rem what is this line for?
************
Why is r13 being stored and to what value? (does it need to be stored?)
Why is put into r14 on return?

First up – are the sources complete? I know Tank has made some welcome updates, but is there an archive anywhere with these modifications as a part of the main source body?

Why is r13 being stored and to what value? (does it need to be stored?)

Looks like its adding temp space on the stack. It could probably be recoded as STMFD R13!,{R1,R2,R14}

Why is put into r14 on return?

And this pulls the temp value off the stack

Perhaps switching off – one or two of the interupts around a replacement SWP.

This is really something we should be regarding with horror these days. Punching out the interrupts “worked” as a quick fix for mediocre design in the eighties. Now, with multicore devices, it is all sorts of icky.

Perhaps first ask why on single threading RISC OS there is an SWP? Is it for an interlock, or just a simple way too exchange registers?

Is there a set of instructions somewhere to tell someone how to go from zero to being able to build Zap? And is there one true source for all Zap’s source code?

Perhaps first ask why on single threading RISC OS there is an SWP? Is it for an interlock, or just a simple way too exchange registers?

It was introduced in ARM3 to allow semaphores in a multi-processor system to avoid IRQ/cache issues. It essentially swaps a register with external memory, bypassing the cache, via a read/write sequence that can’t be interrupted. As a consequence it was very slow and only useful for semaphores and not as a general swap instruction.

Acorn possibly planned to release a multi-processor machine based on ARM3?

The introduction of SWP was nothing to do with multi-core/multi-CPU. It was to allow semaphores and other locking mechanisms to be implemented in user mode for ARX (and any other OS – but ARX was the catalyst)

https://en.wikipedia.org/wiki/ARX_(operating_system)

http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252swp.txt

The introduction of SWP was nothing to do with multi-core/multi-CPU

I believe this was one of Acorn’s original intentions. I’ve just double checked the definition in the preliminary VL86C020 documentation that VLSI provided me with back in 1990, it states:

The data swap instruction is used to swap a byte or word quantity between a register and external memory. This instruction is implemented as a memory read followed by a memory write which are locked together (the processor cannot be interrupted until both operations have completed, and the memory manager is warned to treat them as inseparable). This class of instruction is particularly useful for implementing software semaphores.

The swap address is determined by the contents of the base register (Rn). The processor first reads the contents of the swap address (the external memory is always accessed, even if the cache contains a copy of the data). The processor then writes the contents of the source register (Rm) to the swap address, and stores the old memory contents in the destination register (Rd). The same register may be specified as both the source and destination.

The LOCK pin goes high for the duration of the read and write operations to signal to the external memory manager that they are locked together, and should be allowed to complete without interruption. This is important in multi-processor systems where the swap instruction is the only indivisible instruction which may be used to implement semaphores; control of the memory must not be removed from a processor while it is performing a locked operation.

The ARM610 and ARM710 PRM’s are the same word for word, so Acorn must have been planning multi-processor (or what became the Risc PC) back in late 1989.

According to Wiki:

ARX was a pre-emptive multitasking, multithreading, multi-user operating system. Much of the OS ran in user mode and as a result suffered performance problems due to switches into kernel mode to perform mutexes, which led to the introduction of the SWP instruction to the instruction set of the ARM3 version of the ARM processor.

I’m not sure I entirely buy this, though. Wasn’t ARX canned long before the ARM3 was born (ARX’ failure → Arthur on the original Archimedes)? Or maybe SWP was something that it required that was not added to the ARM2 but made in into the ARM3?

Edit: I notice Jeffrey posted about this. I would have been first, but I got sidetracked tweaking some stuff in another wiki page, and forgot I hadn’t clicked on Save. ;-)

Apart from PC cards in RiscPCs (And Simtec’s Hydra) I never heard any rumours of Acorn working on a multiprocessor system. Though Phoebe’s processor is on a little card and I recall after Black Thursday when Phoebe was cancelled and Peter Bonder was trying to put a rescue plan together he mentioned doing a two CPU processor card as an option for Phoebe. So there must have been some plans. Though there didn’t seem to be any plans for software support as he anticipated supplying the hardware and someone else finding a way of using them.

Then why was it not in the ARMv2?

Presumably they realised the need for it too late. I believe the hardware team had a deadline for when they had to start shipping boxes (probably “as soon as possible”), so delaying the release in order to make changes to the CPU wouldn’t have been possible (plus they decided to ship with the hastily-thrown together Arthur instead of ARX, and being single-threaded/single-tasking down to the bone meant that Arthur didn’t have much need for high performance thread synchronisation primitives).

Also why did they bother to export a signal that could be used to lock the bus?

ARX needed a SWP-like instruction for its synchronisation primitives, but once that basic need was identified I guess they realised that making the operation atomic at the bus level would be useful for any future multi-processor systems.

Also why did they bother to export a signal that could be used to lock the bus?

No need, that’s not where the problem lay. Semaphores/mutexes are a software issue, not a hardware one.

Remember – the “coprocessor” interface of the ARM2 was not really intended for multiple independent processors, it was for assistant coprocessors, namely the FPA (and anything that would behave in a similar manner).

The problem with SWP was that it is intended to be used as a semaphore/mutex. The traditional way to deal with this is to kill off all interrupts, update the data, then turn the interrupts back on. However, as I have said, banging the interrupts is icky. So SWP provides a similar functionality in a self-contained instruction. Plus, it saves a lot of logic in determining what state the interrupts were prior to entry to the function (if they were already off, you probably ought to leave them that way). If you recall, the original ARM’s FIQ code was supposed to run on from the FIQ vector and not mess around doing unnecessary things, so semaphores there would ideally want to be quick and painless.

Apart from PC cards in RiscPCs (And Simtec’s Hydra) I never heard any rumours of Acorn working on a multiprocessor system. Though Phoebe’s processor is on a little card and I recall after Black Thursday when Phoebe was cancelled and Peter Bonder was trying to put a rescue plan together he mentioned doing a two CPU processor card as an option for Phoebe. So there must have been some plans. Though there didn’t seem to be any plans for software support as he anticipated supplying the hardware and someone else finding a way of using them.

The Phoebe was designed from the ground up to be a multi CPU system, with an OS other than RISC OS on it. Time constraints and the usual slippages meant the first version was to be single CPU and RISC OS based.

“Processor expansion card:Interface to support upto 4 × 233Mhz StrongARMs on single processor card) . The card will not form part of this project. "

“IOMDII (Chandler) is a new memory and I/O controller chip developed for Phoebe. It is designed to work with StrongARM in both single and multiple processor operations, allowing upto 3 separate local bus masters using a modified version of the open bus system. The intercommunication between multiple processors will be achieved by using an internal SRAM area with binary semaphores and circular lists. "

I would volunteer [muggins (at) svrsig (dot) org] to help in updating Zap because I use it a lot, but would need some guidance.

Before we even get to updating it, what about the original issues summarised by Sprow at the start of this thread – has anyone picked any of these up?

And is there one true source for all Zap’s source code?

Isn’t that one of the things which needs to be looked at first: getting the Zap Developers’ code into a new source repository somewhere and then making sure that all of the work by Tank is merged in correctly. There’s no point even thinking about fixing issues until we know that they’re still there in that form in the latest version.

Is anyone looking at this, or are we all just assuming that Someone Else Will Do It? As Sprow said, the first steps are all non-programming tasks.

Isn’t that one of the things which needs to be looked at first: getting the Zap Developers’ code into a new source repository somewhere and then making sure that all of the work by Tank is merged in correctly. There’s no point even thinking about fixing issues until we know that they’re still there in that form in the latest version.

Is anyone looking at this, or are we all just assuming that Someone Else Will Do It? As Sprow said, the first steps are all non-programming tasks.

It would appear that the source now exists on GitHub

But this would appear not to include Tank’s updates

OK, I guess I should have more closely read the first post in the thread…

Peter: Thanks for the Phoebe info. Out of curiosity where did you garland it from?

Does anybody have any thoughts regarding what sort of licence should be applied to Zap?
I would ask people to consider something (anything) other than GPL – as this would have important conséquences for third party applications that use the ZapRedraw module…

Does anybody have any thoughts regarding what sort of licence should be applied to Zap?

“Should be applied”? Surely it is licenced in some way already, and this is unlikely to be changed if you consider the number of contributors over the years.

I never saw any indication that Zap or parts of it are licenced under the GPL, why do you bring that up? And why would it change anything wrt ZapRedraw – it is a module, and therefore it is a classic example of something to be distributed “side by side” aka “aggregated” because it is not linked to the other software.

Original Zap by Dom Symes was under GNU Emacs General Public Licence, which is not considered “viral”.

“Should be applied”? Surely it is licenced in some way already,

Of course it is already licenced in some manner; however wasn’t it omitted from the SD image exactly because distribution terms and such were not evident.

and this is unlikely to be changed if you consider the number of contributors over the years.

And this is something that would need to be looked into. I just took a look at the ZapRedraw module and it contains a one line copyright message. That’s it. And?

Sure, a couple of decades ago it could just be understood that releasing the source means that you could use it – but in this day and age… :-/

I never saw any indication that Zap or parts of it are licenced under the GPL,

If one is looking to slap a label on it, then one might wonder what sort of label it would be. :-)

it is a module, and therefore it is a classic example of something to be distributed “side by side” aka “aggregated” because it is not linked to the other software.

One would say yes, but the GPL FAQ specifically forbids supplying a GPL DLL with a VB application. While the FAQ isn’t the GPL, it suggests the mindset is anti anything that isn’t GPL, so mixing could be…problematic.

Original Zap by Dom Symes was under GNU Emacs General Public Licence, which is not considered “viral”.

Can this be considered authoritative?

GPL is one of the huge limiters that has held Open Source back.

Not really. Companies are using Open Source code since the early beginning of computing. But it was almost a pico phenomena. GPL changed that.

Now, some “companies are reluctant to use the source, and thus we miss out on the potential improvements that could have been.”

Before, most “companies use the source but NEVER publish their modifications, and thus we miss out ALL the improvements done.”

Very big difference.

Peter: Thanks for the Phoebe info. Out of curiosity where did you garland it from?

From the “Phoebe (RISC PC II) Functional Specification” that was given to Acorn Registered Developers.

Which is available here, if anyone fancies some light reading!