Circling FPE

Ref the changes made to FPE – what is the best way forward for programs using Floating point code.
Are Draw Paint Vector going to make use of hardware FPE on new machines?

Ie using a updated FPE module on machine’s that can handle them.

Are Draw Paint Vector going to make use of hardware FPE on new machines?

Only if Draw changes from using integer arithmetic – which is faster even if you’ve got hardware FP, and more economical of file sizes, and absolutely fine for the purpose unless you’re really trying to make images you can zoom down to 0.02 thousandths of an inch, or out to over half a mile…

I think Colin is referring to Draw (application) which does use FP when objects are scaled / rotated / transformed. There was a gripe about it a couple of months back. Rather than changing to VFP, it’d be better to go integer!

Draw (application) […] does use FP when objects are scaled / rotated / transformed.

It does? Why the hell does it do that? Ah…I suppose it’s the ready availability of FP trig routines, and the absence of integer ones? Pity…

(I’d assumed he was talking about the Draw application, but knowing that Draw files are all integer, I’d assumed the app was too…)

Rather than changing to VFP, it’d be better to go integer!

Absolutely!

ready availability of FP trig routines

All you have to do is use FP once to generate the matrix, then transform using that. Which it doesn’t.

See https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Draw/-/blob/master/c/DrawTrans

All you have to do is use FP once to generate the matrix

Indeed. Not really worth writing integer trig routines since you only need them once! Not worth bothering to use hardware FP, either, if you only use FP once, although you might as well if you know it’s there.

Not worth bothering to use hardware FP

Norcroft C doesn’t have a soft-fp option though ;-)

PipeDream and Fireworkz have always used fixed-point integer transforms for Draw objects (e.g. when constructing charts).

Norcroft C

I still haven’t got round to serious thinking in C; I doubt I ever will now! BASIC or Assembler for me – or languages that are pretty much (or entirely) obsolete…

Not worth bothering to use hardware FP

Norcroft C doesn’t have a soft-fp option though ;-)

Yes it does. It’s one of the (multitude of) APCS options, so for example if you do *CC -c myfloatyprog.c -apcs 3/32/softfp it’ll spit out code where all floats are held in the integer registers and all maths operations result in a function call. The older ARM tools manuals list what the various functions do if you can’t figure it out from the name, eg. fadd adds two floats, dadd adds two doubles.

Caveats:

• Of course there aren’t any implementations of those library functions, so you’d have to write your own
• It’s not the normal APCS option for RISC OS, so it may be buggy or not especially well tested
• It’s not mentioned in the manual so might change on a whim

Someone must have an implementation somewhere.

Could be a stepping-stone to a VFP implementation for Norcroft. Could have VFP-only library for modern h/w, and VFP/FPA selectable at run-time for apps which require legacy compatibility (or indeed pure s/w implementation). I’ve used some of Sun’s open source f.p. libraries in the past, might be worth another look.

I’ve used some of Sun’s open source f.p. libraries in the past, might be worth another look.

I think “Berkeley SoftFloat” by John Hauser is used in many projects. Friendly BSD license, too.

• http://www.jhauser.us/arithmetic/SoftFloat.html
• https://github.com/ucb-bar/berkeley-softfloat-3

Berkeley SoftFloat

Thanks – I’d heard of that but have yet to use it.

Well, I spent 50 minutes yesterday looking at the hourglass while Artworks resized a 5MB Draw file* (exported from a RiscOSM map of west central London covering about 200 square miles, so not short of detail), during which the machine was unresponsive (where’s CMT when you need it?). The resize wasn’t quite right, so the adjustment took another 50-odd minutes…. Would hardware FP have helped this?
[*I know a sprite export of the same file would have resized in seconds, but sometimes you need to go the vector route]
EDIT: I’m running the stable 5.28 OS version, dated 19-Oct-20, so not the version with the new FPE referred to above.

I can’t answer regarding hardware FP, except to say “personally, I suspect it might”.

But 50 minutes to process 5MB? That’s truly dreadful. It takes less than that to build the entirety of the OS from scratch!

Additionally, it shows the problem of not considering lengthy operations and that such things might require yielding to other programs on a regular basis. Given that RISC OS is a cooperative system, the software must cooperate.

Does the Draw File in question have any extensions that require Artworks?

Not as far as I know. I’ve tested the same Drawfile in Ovation Pro and Techwriter, and in both cases the resizes take seconds. So it looks like it’s down to something in ArtWorks.

So it looks like it’s down to something in ArtWorks.

I guess probably ArtWorks uses FP instead of integer arithmetic. While I understand that Draw apparently uses FP for rotations, I can’t imagine any reason why it would for resizing. I can’t imagine why ArtWorks would either, but it would explain the difference.

It’s noticeable, and surprising, that ArtWorks takes so long to import big Draw files. I’m sure ArtWorks uses a completely different format internally, but I’m still amazed by how long the conversion takes. I wonder whether there is some inefficiency in the memory allocation, and perhaps it is copying the data around many times unnecessarily? Martin Wuerthner is the only person who would be able to explain this.

I suppose when ArtWorks was originally developed, gigantic Draw files might have been hard to come by for testing. You’d never get to 5MB creating a Draw file by hand, unless it had a lot of embedded bitmaps, which ArtWorks probably wouldn’t have to do much with.

I find it sobering to think that I can move data from spinning rust over a network faster to more spinning rust much faster than I could from memory-to-memory on an A440, which we thought was fast!

I would think that a 128KB draw file would have taken as long to process in the same manner as a 5MB Draw file does on a modern RISC OS System.

I think it depends upon what is actually happening. If we assume a Draw object is twenty bytes long (and, note, I just plucked that figure out of my ass), then the 128K file would have around six and a half thousand object that need processed.
The five megabyte file, on the other hand, will have over two hundred and sixty thousand.

That’s a forty fold increase in the number of objects to process, which – yes – you would have thought differences between old and new hardware would have smoothed over, so I would imagine there’s something else going on here. Perhaps it allocates a temporary block of memory in case something fails? Or maybe there’s some clever optimisation to speed things up (ArtWorks was known for being quick) that falls apart when given a huge file?
I don’t know. It just seems bizarre that ArtWorks takes that long.

Just for the lulz…

*BASICFPA
ARM BBC BASIC VI (FPA) (C) Acorn 1989

Starting with 4188412 bytes free

>AU.
   10t% = TIME
   20x = 1.23
   30y = 4.56
   40z = 7.89
   50
   60FOR l% = 1 TO 5248000
   70  a = x + y + z
   80  b = x * y * z
   90  c = x ^ y ^ z
  100NEXT
  110PRINT TIME - t%
  120
Escape
>RUN
     16110
>SAVE "$.__ttest"
>*BASICVFP
ARM BBC BASIC VI (VFP) (C) Acorn 1989

Starting with 4188132 bytes free

>LOAD "$.__ttest"
>RUN
      2536
>*BASIC
ARM BBC BASIC V (C) Acorn 1989

Starting with 4190460 bytes free

>LOAD "$.__ttest"
>RUN
      1856
>

It’s a pretty arbitrary test, but as you can see the FPE is painfully slow, taking just shy of three minutes to do this test.
VFP does it in twenty five seconds.
Even more astonishing, BASIC’s internal FP routines (lower precision, mind you) chunder through this lot in eighteen and a half seconds, effortlessly knocking almost a third off the hardware FP speed! That being said, I wonder if there are overheads in calling VFP from BASIC? At any rate, both of them are orders of magnitude better than FPE.

So, if ArtWorks is making use of FPE…… ;-)

which we thought was fast!

I remember 1200/75 modems, and when 2400 baud came along (I have one someplace), people were like “this is the fastest it’s possible to get down a phone line”.

Tell that to my Livebox, that’s chugging along somewhere between 3 and 4 *mega*bits (depending on the weather, phase of the moon, etc).

(again)

which we thought was fast!

I recall the days when Econet (from a clunky FileStore) seemed fast. It was pretty nippy compared to loading stuff off 5.25" floppies using DFS. Was DFS bad or those drives just really slow?
Both were a revolution ¹ compared to tape.

¹ <groan>

Econet and FileStore were pretty good for their day. Writing the FORTRAN compiler in 1983/4, I was using OS_GBPB to read blocks, and it worked well over Econet. Much less so on DFS to my surprise! ISTR DFS implemented OS_GBPB by calling OS_BGET <n> times…

I’ve just unsqueezed and looked at the executable for ArtWorks 1.5-something, from the mid 90s.
There’s no FP. So it’ll be some sort of fixed point maths. Would be quicker…

Fired it up under Aemulor to look at the code for the Transform and Draw import modules (because they’re compressed on disc). No FP there either.

ISTR DFS implemented OS_GBPB by calling OS_BGET times…

Not unheard of. I was able to run my Micron EPROM programmer on an A5000 using 65Host and the massive BBC I/O podule.

Loading and saving ROM data took quite a bit longer than actually programming the EPROM. I suspect it was doing the file access as a mass of byte ops.

Econet and FileStore were pretty good for their day.

Ever used an MDFS? I’m gutted mine blew up, because comparing the FileStore to the MDFS is a bit like comparing a Reliant Robin to the Ark Royal.