Just something not so important

It’s common practice to compile or write RISC OS software so that it runs on everything from ARM2 to ARMv8.

Indeed, but in talking about OpenCL and emulators we are exploring ways in which non-ARM computation cores can be utilised, and Michael’s 64bit project is a useful case. I was using this to explore a more portable model that has application to the GPU, FPGA and Emulator cases. But even within the ARM family there’s great differences in floating point architecture, and this does entail multiple builds already. Code generation from an intermediate format obviates that. I suggested wasm as it is a RISC-like assembly language (with SIMD instructions) that maps quite directly to ARM, allowing efficient code generation on the various cores people are already using, while also not building-in a future emulation requirement.

One approach to allow calls to many RISC OS APIs is if a SWI that is not marked as thread safe is called in an extra thread

This isn’t really the thread for that discussion, but I maintain strongly that you cannot have “RISC OS” as it is commonly understood multithreaded. You can have a small OS with some familiarly-named SWIs, but you cannot have the same API, implementation or behaviour on multiple cores. You must necessarily have only a small subset. Your mention of TaskWindow is illustrative:

• Often thought of as “pre-empted RISC OS”
• Only half a dozen SWIs are intercepted
• VDU is completely broken inside the TaskWindow (even PrettyPrint doesn’t work)
• Almost any other SWI has the potential to cause significant problems

It is just sufficient to run the most trivial of stdin/stdout utilities… and that is within the single-threaded model that almost all of the RISC OS API requires.

there are many ways to be single core thread-safe but be multi-core thread safe.

I’m not sure what you’re saying here. RISC OS is already multithreaded (it has interrupts! multiple stacks!), but few SWIs are re-entrant. So there has always been a huge difference between what the ‘foreground thread’ can do, and what ‘background threads’ are allowed. A multiprocessor model can either treat all other cores as background threads, or treat the cores more like separate computers on a network. What you certainly can’t have is multiple cores calling the vast majority of SWIs.

This is why I think it’s much more useful to think of additional cores having a light Tube-like OS or, as is the wasm model, nothing but function pointers. You can’t have additional cores calling WindowManager, MessageTrans etc. You can’t have one core calling WrchV while another is issuing Byte,218 or 236.

There are plenty of modules that sit on vectors and maintain a threading count to alter their behaviour (to avoid recursion) so you can’t have multiple cores calling the same vector simultaneously, so you need locks. This immediately leads to race conditions because vector claimants inevitably call other vectors. You’ve got thirty years of code and hundreds and hundreds of modules.

This is why I keep saying that additional cores must be seen as computation units. The RISC OS API is basically Highlander when it comes to threads – There can be only one.

https://twitter.com/QtARM/status/1199824296153100289

I need to stop doing demos! :D

Half of my boot ups leads to blurry screen … so need to go back to that problem.

And so I have read various docs and papers and blogs about WebAssembly and I am not really much wiser, so I’ll do the advocatus diaboli due to my sceptical nature about the wheel-reinventing nature of IT…

what is the advantage compared to e.g. Java bytecode or LLVM Bitcode?

Versus Java, it’s faster, more secure and much, much smaller.

Faster: not according to the sources I read. In real-world benchmarks (i.e. a bunch of people rebuilding SPEC on WebAssembly), WebAssembly is half as fast as native code, while e.g. Hotspot Server JVM sometimes beats native code (once warmed up, or if jaot is used).

Secure: Citation needed. Both the JVM and WebAssembly can do sandboxed execution. Whether one is more secure than the other seems to rest mainly on the quality of the implementation. In theory, both are secure.

Smaller: it depends. I said “Java bytecode” for a reason – this does not include the whole Java SE platform. There are many embedded JVMs that come only with a small subset of Java SE platform, which is basically equivalent to the WebAssembly approach. And WebAssembly is a bit simpler, since I think it does not supply a threading environment and a GC.

And a significant advantage is that there isn’t an implicit humungous standard library (4,500 classes in Java now?!).

There is no such thing “implicit” in Java Bytecode, and I most certainly did not ask for a comparison between WebAssembly and Java SE platform, which would not be a sensible comparison.

Whether it is an advantage to have only a minimum runtime specified – it depends on the complexity of the task at hand. There is very little that basic WebAssembly can do right now (apart from running micro benchmarks quite fast…). Need a UI? Need networking? Need data structures? Welcome to library hell. And cross-platform hell.

As for LLVM, wasm is totally portable – the same binary runs on any platform. That isn’t true of LLVM’s intermediate representation. However, LLVM IR can apparently be converted to wasm.

LLVM IR might be non-portable because platform-dependant stuff was thrown out at the preprocessor level (something that WebAssembly also does not care for) – I cannot see how WebAssembly is different from LLVM IR from a portability standpoint.

Regardless, I think there are significant advantages to adopting an international standard over something that only works on this Broadcom chip or that particular ARM board. A ‘multicore’ system that could work inside an emulator without having to emulate additional cores is also very attractive.

Yes, I absolutely agree about the theoretical value of being able to use proven technology and code for CPU abstraction. However, it is unclear whether WebAssembly is a good long-term solution. At the moment, it is in a hype-state in Browser world. Such things tend to be sporadic sometimes. We are quickly heading for Chromium-Everywhere at the moment, which makes it difficult to judge if the future WebAssembly incarnation – if it will exist – will still be a viable solution for our use case a few years on from now.

Whether the other two alternatives are better – I have no idea. Our legacy codebase is very much tied to the C family of languages, so the natural thing to choose would be LLVM – LLVM IR seems to be stable, native compilation is available (for the old-schoolers amongst us), and it is well-established. While I personally think that a minimal JVM (maybe JamVM) would be an interesting runtime platform, using languages which are typically compiled to bytecode has no tradition on our platform, so it would be an academic solution without going the whole hog and port the complete Java SE Platform (which is…erm…ambitious).

But we (as in “The RISC OS community”) don’t even have the manpower to maintain the GCC ARM backend legacy targets to keep being able addressing all ARM variants from ARMv2 up to ARMv8.x with one binary. A pragmatic approach might be making source available via an Escrow-type arrangement to interested parties whenever ARM does their next backward-compatibility breaking change. But all that does not attempt to solve the whole multicore-heterogenous-multicomputing scenario.

an implicit humungous standard library

Don’t forget different versions of said libraries. ;-)

Thing is, Java (and its relatives) are trying to be a jack of all trades. Right now I’m listening to PPNR on a little Android app. There is no doubt that the app will have pulled in library functions to retrieve data, to stream audio, to handle controlling and using speakers and headphones. It’ll just call in prewritten libraries for all that, rather than reinventing the wheel.
Oddly enough, that’s pretty much exactly what I did with my NetRadio. And that was written in sort-of C.

Trust me, if/when WebAssembly is mature, it’ll have a tonne of libraries, a mess of versioning, and all the cruft a mature thing accrues.

On the one hand, wasm runs in a sandbox so cannot mess with your system

That’s the theory.
Reality is often different.
And in this reality, the sandbox is only as good as the people that coded it. Never ever say “cannot mess with your system”. The best you can hope for is “should not mess with your system”.

No it isn’t. Not on my machine. Do you see?

Nor my machine. But that’s not really the point. You or I could go and buy a Pi3/Pi4 and dive into AArch64, and be using ARM64 code within days (however long it takes for the hardware to arrive). You cannot say that of technologies like WebAssembly for which there currently exists nothing whatsoever for RISC OS; and at the very least would need some sort of compiler (it’s ARM32/64, could use an existing) and some sort of library. I think that – the library – is where you’ll come unstuck. There will be lots of expected behaviour, and I wonder how much will be completely alien to RISC OS’ way of doing things. Let’s just toss out some concepts – threads, subprocesses, and tasks. On other systems, there is a subtle but important difference between them, plus the expectation of being able to multitask processes “in the background” completely away from anything that even remotely resembles a GUI.

and implicitly claiming one knows better than Mozilla, Microsoft, Google, the W3C and Brendon Eich.

I don’t think anybody is claiming to know better. But perhaps one should not put those names up on a pedestal.

For example, read this: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API
Introduced as a W3C standard, implemented in Firefox (etc). Now deprecated (in the same of going away soon if it hasn’t already).
I’m sure they meant well, but maybe it should be mandatory for any standards organisation to have to commission research on “how can this API be hijacked/abused?” prior to introducing it.

Google. How about the proposals to change the WebRequest API which has the side effect of breaking numberous content blockers due to restrictions and limitations in the suggested declarativeNetRequest API. Google’s primary focus is not in improving internet security. Their primary focus is getting paid for advertising crap at you. Never forget that.
Never forget, as well, that Google has a veritable graveyard of “best hot sh*t” projects that were abandoned. But not abandoned to open source so somebody else can take over if they want, no, properly abandoned as in “gone”.
Remember Google Cloud Print? Ever use it? It’s hasta-la-vista this time next year.
Full and depressing list: https://killedbygoogle.com/

WebAssembley is an interesting idea, certainly. Just not something I would want running on any of my systems. I’m afraid I have issues with random third parties thinking that they can run their code on my machine, especially given as how much junk an average website thinks it can include with its content. Most browsers, out of the box, are not able to selectively allow what can and can not run. This is why add-ons are so important, where things can be disallowed until they are explicitely marked as permitted.
Why? It’s not paranoia. It’s logical.
https://cyware.com/news/new-malvertising-variant-leverages-google-ads-to-serve-malware-through-legitimate-websites-e0936a88
[I’ve not trawled Google for an old story to make a point, that’s from THIS October; as in last month]

Trust me, WebAssembly will get attacked harshly when it is big enough to make it a worthwhile target.

For what it’s worth, I’ll put my money on Michael. Some of the most interesting things are born of scratching personal itches. And yes, it might only work on certain systems right now, but he has already demonstrated code running on one of the other cores. Can you, or anybody, demonstrate anything even remotely to do with RISC OS when it comes to WebAssembly?

Steffen wrote:

WebAssembly is half as fast as native code

At worst. In some cases it’s within 10% of native. However, there’s clearly improvements to be had in code generation versus native compilation – I suspect register allocation will prove to be at the root of this.

WebAssembly is a bit simpler, since I think it does not supply a threading environment and a GC.

Yeah precisely.

I cannot see how WebAssembly is different from LLVM IR from a portability standpoint.

Ooh heavens. Endianness, structure alignment, size and sign of primitives. What does ‘char’ mean on your compiler/platform… because that’s what ends up in the LLVM IR.

Need a UI? Need networking?

There is no implicit library in WebAssembly (in general, though WASI aims to specify one). There cannot be any UI access from other cores (which is our specific usage case here). The code can only access functions provided by the caller.

Yes, I absolutely agree about the theoretical value of being able to use proven technology and code for CPU abstraction.

Glad it’s not only me! ;-)

My preference for wasm is because of its absolutely minimal scope – fixed memory, assembly code, caller-provided functions, and that’s all. JVM implies much more (including GC AIUI) and LLVM feels much more heavyweight (and is not as portable).

Rick worried

in this reality, the sandbox is only as good as the people that coded it

A little background for those who haven’t trawled the specs: Your wasm code is given access to a single block of memory. It cannot access memory outside that. It does not know its address. It does not know the addresses of any functions. It cannot specify a memory address under any circumstances. It cannot allocate or free memory. It cannot open files. It cannot call the OS. It cannot modify itself. All it can do in general is return a value. You can give it some function pointers if you wish, in which case it can only call those.

It is not a program in its own right, it is a computation thread, basically. It can be an infinite loop, but so can anything.

Can you, or anybody, demonstrate anything even remotely to do with RISC OS when it comes to WebAssembly?

Are you suggesting I should implement a WebAssembly implementation for RISC OS in order to better argue for the implementation of a WebAssembly implementation for RISC OS?

I see what you’re doing there and it won’t work ;-)

Are you suggesting I should implement a WebAssembly implementation for RISC OS in order to better argue for the implementation of a WebAssembly implementation for RISC OS?

Seems a bit excessive to argue a point.

A simple proof of concept would probably do. :)

Well it’s not very compelling in isolation.

A textual wat file (white icon), assembled to a wasm binary (purple icon), and then turned through the naffest of naff code generation and a trivial Utility wrapper into a RISC OS executable (which I’m calling a warm for the lulz):

The code generation here is rubbish, but better than an interpreter. I am not proposing writing a good code generator. I believe ARM have already done so.

The compelling bit is that the wasm can be written in loads of different languages and compiled on any OS. It can even be tested in a browser if you want (but not a RISC OS browser, obvs).

Heavens, it ought to be possible to write RISC OS Modules in any language that compiles to wasm – you’d just need to export some specific entry points with predefined function signatures.

However, my suggested purpose is as a representation of a worker function that can be invoked on whatever additional computation engine you have available – other ARM cores whether 32bit or 64bit, GPU, FPGA, emulator host processor, or run locally on the same CPU.

Why run one RISC OS , when you can run TWO (or more)..

Bootlog, the error is me skipping filesystem things..
bq.RRA53 running
OSM CHECKBOUefTo rAe5 3
o A_A5d3d RBeAfM
drAed dOeSd_ A
rdBReAfMo
eA 5O3S _ASdtdaerdt

A53 Before OS_Start
MMU up , runningA
HADM5I3 lMoMgU buopo t, frfuna0ni00n0g0A

0USDBM IL OlGo:g fb9odo8t 00f0f0a
LI0R0Q0
9 oUgSfB9 aL0O0G:00 0f
id8HA0L0_00In
RQI
0 V_iLdoegof_9Ian0i0t0
0
80HMAPL_IDIRn:it
L 0A0530 10H0A
L I NCITTR
5AR 5c3: A 05030 0A50033 7A
53V iA5d3eo 1A
5 V iAd5e3o 2A
33 ViAd5e3o
U
SVBidIenoi4t

NVMemory_Init
Timer_Init
Interrupt_Init
GPMC_Init
2: A53 A53 A53 A53 A53 A53 A53 A53 A53
HAL initialised
IICInit
ClearWkspRAM
HAL_CleanerSpace
IMB_Full done
InitDynamicAreas
InitVectors
InitIRQ1
Get timerdevice
IMB_Full A53
VduInit A53
ExecuteInit A53
Get timerdevice
IRQENABLE: 00000077
Pending irq num: 000003ff
KeyInit A53
OscliInit A53
Enabling IRQs A53 A53 A53
IRQs on A53 A53
Debug terminal on A53
HAL_InitDevices A53
A53 InitVariables
A53 AMBControl_Init
ModuleInitForKbdScan
init mod UtilityModule
init mod PCI
init mod FileSwitch
init mod ResourceFS
init mod TerritoryManager
init mod Messages
init mod MessageTrans
init mod UK
init mod SharedCLibrary
init mod BufferManager
init mod DeviceFS
mod init (kbdscan) done
ReadDefaults
InitHostedDAs
MouseInit
A53 A53 A53 A53 A53 ModuleInit
init mod WindowManager
init mod TaskManager
init mod Desktop
init mod ScreenModes
init mod IMXVideo
init mod BASIC
init mod BASIC64
init mod ColourTrans
init mod Debugger
init mod DADebug
init mod Portable
init mod International
init mod InternationalKeyboard
init mod RTSupport
init mod DisplayManager
init mod DMAManager
init mod DragASprite
init mod DragAnObject
init mod Draw
init mod FileCore
init mod RamFS => error: RAM disc size too small
init mod Filer
init mod FilerSWIs
init mod FontManager
init mod FPEmulator
init mod VFPSupport
init mod Free
init mod Hourglass
init mod IIC
init mod InverseTable
init mod Obey
init mod Pinboard
init mod PipeFS
init mod RAMFSFiler
init mod ResourceFiler
init mod ROMFonts
init mod SpriteExtend
init mod ShellCLI
init mod BlendTable
init mod SpriteUtils
init mod Squash
init mod SuperSample
init mod SystemDevices
init mod TaskWindow
init mod WindowUtils
init mod FilterManager
init mod ColourPicker
init mod DrawFile
init mod Filer_Action
init mod DOSFS
init mod SCSIDriver
init mod SCSISoftUSB
init mod SCSIFS
init mod SCSIFiler
init mod ScreenBlanker
init mod ScrSaver
init mod FSLock
init mod SoundDMA => error: No sound controller devices found
init mod SoundControl
init mod SoundChannels
init mod SoundScheduler
init mod WaveSynth
init mod StringLib
init mod Percussion
init mod SharedSound
init mod BootCommands
init mod AUNMsgs
init mod MbufManager
init mod Internet
init mod Resolver
init mod Net => error: AUN not configured
init mod BootNet
init mod Freeway
init mod ShareFS
init mod MimeMap
init mod LanManFS
init mod DHCP
init mod !Edit
init mod !Draw
init mod !Paint
init mod !Alarm
init mod !Chars
init mod !Help
init mod Toolbox
init mod Window
init mod ToolAction
init mod Menu
init mod Iconbar
init mod ColourDbox
init mod ColourMenu
init mod DCS
init mod FileInfo
init mod FontDbox
init mod FontMenu
init mod PrintDbox
init mod ProgInfo
init mod SaveAs
init mod Scale
init mod TextGadgets
init mod CDFSDriver
init mod CDFSSoftSCSI
init mod CDFS
init mod CDFSFiler
init mod UnSqueezeAIF
init mod EtherUSB => error:
init mod DDEUtils
mod init done
Service_PostInit
callbacks A53 A53 A53

RISC OS 597MB

Cortex-A53 Processor

EError: Internal error: abort on data transfer at &FC045D90 (Error number &80000
002)
*pyhstat0: 000000f3
USB_Init
NVMemory_Init
Timer_Init
Interrupt_Init
GPMC_Init
HAL initialised
IICInit
ClearWkspRAM
HAL_CleanerSpace
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
InitDynamicAreas
InitVectors
InitIRQ1
Get timerdevice
IMB_Full
VduInit
ExecuteInit
Get timerdevice
IRQENABLE: 00000071
Pending irq num: 000003ff
KeyInit
OscliInit
Enabling IRQs
IRQs on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInitForKbdScan
USBCONTROLLERINFO: 00000000
USBCONTROLLERINFO2: 00000010
IRQENABLE: 0000003a
Pending irq num: 000003ff
Reset CMOS
ReadDefaults
InitHostedDAs
MouseInit
ModuleInit
*

And now video working display in window on A72

https://twitter.com/qtarm/status/1201806847038152705?s=21

Just got desktop and usb on A53. I use one controller for each cpu.

Bootlog, the error is me skipping filesystem things..

Yeah… but isn’t it the “filesystem things” that’s most likely to blow up in this sort of scenario? ;-)

Still… damn.

Why run one RISC OS , when you can run TWO (or more).

That was part of the logic behind me mentioning the JaffaSoft messaging setup – you just need to pass the messages round different instances.

As Rick says “filesystem things” might be an issue but if only one instance has direct access to the filesystem and everything else goes via that.
You could also strip down the instance with the active filesystem access to make the file access more responsive. As long as everything looks normal to an application in the other instance(s) things will probably not hit any bumps in the road.

I implemented usb. Not optimal but the A53 run without error.
https://twitter.com/qtarm/status/1201958176482119680?s=21

Btw when is sprite and font area set? When booting the 53 they doesn’t get set. Had the exact same problem on rk3288. Works just fine on main riscos.

Why run one RISC OS , when you can run TWO (or more)..

That’s basically AMP.

Con: it’s not as transparent as SMP
Pro: what will work on an AMP system will work on a cluster

I can’t run a proper !boot. It crashes immediately. Is that related to missing areas?
*where tells me in module area , but which module and it has to be the very first thing that !boot does..

Btw when is sprite and font area set? When booting the 53 they doesn’t get set. Had the exact same problem on rk3288. Works just fine on main riscos.

They’re created by InitHostedDAs

That function is called, no error checking , need to add debug. Both cpus runs the same rom. The only difference is that the second one isn’t calling interrupt init. The first cpu sets affinity for the second, timer and usb.

Setting defaults to something gives me desktop with bitmap font. ROM apps resets the cpu. Load from disc works, at least the benchmark.

Hum… http://riscoscloverleaf.com/ ?

Interesting. Seems to be incomplete in many areas, but it does mention
‘RISCOS Developpment Ltd.’ but whether that is really
‘RISC OS Developments Ltd.’ perhaps needs clarifying.
Although it is clearly about RISC OS, it always refers to RISCOS.

Ahah! Facebook mentions ‘Planned crowdfunding start is April 2020.’

Perhaps this should be a new thread?

“Sign up and get a discount
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus.”

Umm…

Edit: Some broken links in the footer too.

Probably some boilerplate text to be something visual before actual content is available (like, perhaps, how the hell they plan to do this, and does it conflict with RODev’s current efforts?).

What is more concerning to me is all the REDACTED when you look at the domain record. I know Germany has a strong concept of privacy, but I thought that hiding contact details from public view was for private individuals?

So – lofty goals from an unknown wanting to raise money by crowdfunding… Hmm…

Stefan Fröhling (7826) and Aleksey Murushkin (Cloverleaf) (8233) have both posted queries here – and are the names near the bottom of the CloverLeaf main page.

Good spotting. Their post summaries are here and here.

Stefan was present at London show, and was demoing a work in progress chat client.