FP support

With gcc4.7.4-rel2 the command gcc main.c gives

Undefined instruction at &000080C0

#include <stdio.h>
#ifdef __GNUC_MINOR__
#define MESG "defined"
#else
#define MESG "not defined"
#endif
int main (int argc, char **argv)
{
printf("%s %d %d\n",MESG,__GNUC__,__GNUC_MINOR__);
}

That worked for me on a RPi 1, today’s nightly ROM. Do you have sufficient Wimpslot? I used 16000K and it compiled fine (‘defined 4 7’ being the output).

(noting that it wouldn’t compile if _ GNUC_MINOR _ was not defined since there would be an unknown symbol in the printf)

Do you have sufficient Wimpslot?

30000K

The commnd gcc --version in a taskwindow gives Internal error: undefined instruction at &00008038. In case there was a download error I am now downloading the Sep 1 build of GCC4_4.7.4-Rel2-1.zip. Unfortunately I can only get 100kB/s where I live, despite BT’s promises, and the help of one of their engineers last week to check out my house. So is there any way of just downloading the rebuilt gcc without getting the whole zip file?

Nope, same error with new download. So I suspect that I must be doing something wrong. I note that !GCC.bin.gcc is an elf file. Should I be converting it to an aif file first? SharedULib version is 1.13 and SharedCLibrary is version 5.86. RO 5.23 on Rpi 2.

These are the md5sums of the files from build 32 (as linked above):

a383bf159b073d74090b09ac9d29c356 DRenderer_0.56-r-1.zip
a7cae6afcd607a5abd803baf944ad0a4 GCC4_4.7.4-Rel2-1.zip
94a23b316db113ee3528ef45163a27e7 GCC4-C++_4.7.4-Rel2-1.zip
ad24ca3089df2d7817ded77cd1656f47 SharedLibs_4.0-Rel2-1.zip
373d981188122b612a2f7b298fc0d9b2 SharedLibs-C2_4.7.4-Rel2-1.zip
d8bbcc00a259848da0a9b1230c1f6bc5 SharedLibs-C++2_6.0.17-Rel2-1.zip
a89768870ecd86678ae45d751b45ffd0 SharedUnixLibrary_1.13-1.zip

Since they’re all built fresh, there’s no way to upgrade a previous version without downloading them. You may be able to get away without having C++, but I haven’t tested that.

You don’t need to convert anything. Did you download all the parts? !SharedLibs should go in !Boot.Resources, and you need to merge the parts from each archive (ie drop over the existing !GCC or !SharedLibs).

Alternatively leave PackMan running overnight to download and install everything. Once I had added
the pkg/autobuilt path (see previous post) to PackMan’s sources (using iconbar menu), on a fresh RPi disc image it ‘just worked’ for me.

Thanks Theo. I re-downloaded, including C++, and it all works. Thanks again for your patience.

I have just gone through gcc4_7_4-rel2.!GCC.docs.index/html correcting typos and polishing the English, as there were one or two bits that I found slightly confusing. Should I email or upload the corrected version somewhere, so that somebody can check that I have not made matters worse?

I may well have some naive questions to ask about the practical details of compiling and distributing software using shared libraries, but I guess that I should read the literature thoroughly first before firing them off.

Thanks, that would be handy – please mail the GCCSDK mailing list if you’re subscribed (or want to be), else you can mail them to me or put them somewhere. I admit I haven’t looked the documentation at all recently – was going to go through it when I get time to do a proper release (which has been a bit lacking recently).

I get the error “undefined instruction at &00008324” when I try to run Kümmel’s BiLiZo demo program which uses NEON. I am using a pandaboard running RISC OS V5.22 (13/04/15). All Kümmel’s other programs demonstrating either VFP or NEON run fine. I have set the next slot far higher than the required 2MB.

Can you provide an disassembly of the executable around &8324? My guess is it’s using an unsupported instruction, but difficult to tell. Did you build this yourself, and if so, what were the build flags?

It looks like BiLiZo is being naughty and is enabling the NEON coprocessor manually instead of using VFPSupport. So then when something comes along which does use VFPSupport (like SoundDMA), VFPSupport will disable the coprocessor access once the sound code is finished and BiLiZo will crash.

Hi, this is my first post on this forum. I can see elsewhere on this forum that there is a BBC Basic with support for VFP in the assembler but is there a version of BBC Basic with Hard Float VFP for the maths?

is there a version of BBC Basic with Hard Float VFP for the maths?

Not yet, no.

Maybe I’ll have a go at it at some point, it might be a nice break from all the big sprawling features that I’ve been working on recently.

I might add that if I do make some additions to BASIC, that will be one of the interesting things to do, for BASIC VI anyway.

I have manipulated VFP floats from BASIC VI using my experimental Float module.

The reason I ask is that I would like to run it on a Pi Copro attached to a BBC B or BBC Master 128.

You can see all about that over at stardot in the 8 bit hardware section.

Float uses Chebychev polynomials, which are derived from Taylor series expansions. The latter are interesting mathematically, but very inefficient computationally.

The aim with Chebychev polynomials is to have as few terms as possible for the required precision. The number of terms is also governed by the range over which the precision is required, so there is an element of range reduction before actual computation starts. The calculation of the polynomial coefficients for the required precision is not simply done.

The Holy Book for this is ‘Computer Approximations’ by John Hart et al, first published in 1968, half of which is computer typeset tables. The other half is ‘Notes’ on how to use them, but what notes! Continued fractions are mentioned, but only to derive polynomial approximations.

FWIW, the FPE sources reveal that the transcendental instructions are emulated using routines based around those described in ‘Software Manual for the Elementary Functions’ by Cody & Waite

Also they’re emulated via the use of other FPA instructions (ADF, MUF, etc.) – which is great for the 0.1% of people with FPA hardware but a source of extra overhead for those without.

I remember using in my RPC a “SuperFPEm” module that was a FPEm rebuilt for speed. The author (that I don’t remember, will search) found a lot of of overheads to remove, for example. Maybe it would be worth taking a look at this?

I remember using in my RPC a “SuperFPEm” module that was a FPEm rebuilt for speed. The author (that I don’t remember, will search)

Dan “Mech” Maloney.

There was an Iyonix pc version.
https://web.archive.org/web/20040902031342/http://www.mechness.plus.com/

Not sure it works on (more) modern hardware.
It would be probably better to have a VFP version.

Float uses Chebychev polynomials, which are derived from Taylor series expansions.

Does this thread come with subtitles, or maybe pretty pictures that help explain?

I mean… transcendental instructions… VFP is Buddhist?!?

(^_^)

https://www.mathsisfun.com/numbers/transcendental-numbers.html

VFP is Buddhist

Educators often bubble on about maths being oh so logical, so rational. This is bollocks and romantic flummery. Like all human activity maths can be untidy and muddled, nowhere more so than in its terminology and notation. Maths has been evolving for quite a while, and a good deal of its terminologies stem from times when all educated Europeans wrote in Latin or Greek and before concepts had reached their current level of maturity. Furthermore, words like transcendental have now gained a posh penumbra of classicism that they did not have when first used. One of the difficulties of learning maths is that it borrows quite ordinary words and invests them with new and very particular meanings that often have little connection with their vernacular sense (real numbers, anyone?). As time moves on, these words, stuck like currents in the expanding dough of maths, cease to be used in ordinary speech. You cannot separate maths from history (logarithms invented for improving the accuracy of artillery). For me that is a part of its charm. The idea that it is some kind of modern pill that has to be swallowed by schoolchildren if they are to grow up as useful business-fodder (sorry, useful citizens ) is a self-defeating lie.

I should have ranted this in Aldershot – sorry.

One of the difficulties of learning maths is that it borrows quite ordinary words and invests them with new and very particular meanings that often have little connection with their vernacular sense (real numbers, anyone?). As time moves on, these words, stuck like currents in the expanding dough of maths, cease to be used in ordinary speech.

Conversely there are instances of people(s) malaproping (to butcher a word) some valid words used in maths. One such is the ‘merkin’ use of “normalcy” when they should be using normality to describe the state of being normal/standard as opposed being perpendicular to the normal as described by normalcy.

malaproping some valid words used in maths.

An example that I find irksome is the use of epicentre when what is usually intended is centre. They have separate meanings. The epicentre of an earthquake is the point on the surface of the earth closest to the centre of the earthquake. I think that for many people longer words sound more convincing than shorter, and centre is not long enough to sound trendy.

Kidnapping scientific words to use in spurious ways is the mark of a charlatan. Energy ? I always reckoned that perfume manufacturers lost a trick in not using the suggestive phrase magnetic moment .

One of the easier approaches is to base it on the softfp PCS that the compiler already supports

Just tried compiling PipeDream with /softfp: “Fatal Internal Error: FP op 66 unknown” which seems to be associated with fabs(). Surprised it got that far TBH!

Just tried compiling PipeDream with /softfp: “Fatal Internal Error: FP op 66 unknown” which seems to be associated with fabs(). Surprised it got that far TBH!

Well, I suppose I’m nothing if not persistent. Circled back round this week, took a deep breath and managed to get PipeDream running OK in -apcs /softfp mode by implementing (a) macros to stop the compiler trying to (seemingly incorrectly) use some of its built-in functions in that mode that then barfed during compile and (b) enough compiler support functions (well, it’s PipeDream we’re talking about here, so basically all of them!) using VFP instructions for the run-time system. I obtained about a factor of five to six speed improvement when inverting a large matrix (and got the correct result, which is a bonus) that I thought worthwhile persisting with.

So, I now have a support library that consists of a single C header file and ALF library of AOFs from a user’s POV. You just need to include the header, recompile with -apcs /softfp, link with the library and see if it works for you. Any takers? It’s done with reasonable granularity so that if you don’t use floats, the float section isn’t included in the executable.

If the system you run the application on doesn’t have VFP (olde worlde or an emulator), the library will transparently fall back to using FPA instructions. Doesn’t seem much of a performance hit either in that mode given how long it takes to take the undefined instruction trap and decode the FPA instruction on non-FPA-hardware systems.

[Edit: and if you have a modern enough VFPSupport module present, it will use the elementary functions provided by that for the basic trig/power functions in VFP.]

[Edit #2: thank $deity for macros. I haven’t produced that much assembler in a long long time.]