Newshound and Eternal September

Well, it is built with an up to date DDE, and it is built completely – but the Makefiles are old, so: what should the compiler flags be now? They are:

-c -apcs 3/32/fpe2/swst/nofpr -Wp -depend !Depend -DCOMPAT_INET4 -DNEWSHOUND_TCPLIBS -IC:,tcpiplibs:,wimpclib:,<syslog$dir>.C-veneer. -throwback -fnah

wimpclib is one of Joseph’s libraries, and the build dates are all from January this year (i.e. I built them).

I’ve added some more flags in case they make any difference, but I’m not sure they will:

-c apcs 3/32bit/fpe3/swst/fp/nofpr -cpu 3 -memaccess -L22-S22-L41 (the rest as before)

There would be one extreme solution to the reported problems, which is to remove floating point entirely from the application. Might take a while…

Is there a way for the C preprocessor to respond to the type of a variable? e.g. if time_t is defined as an int, compile something, else compile something else? It’s maybe an excessive solution to the difftime thing, but when both the args are of type int (or unsigned int, I forget which, but it makes no difference), then just subtract them – there’s no reason to do a difftime. But if time_t were ever redefined, it would be most elegant to respond automatically. Best I can think of is to check sizeof(time_t).

Floating point is used elsewhere too.

And why are only some people seeing these problems? Why don’t I see them at all, ever?

And why are only some people seeing these problems? Why don’t I see them at all, ever?

I know how frustrating that is. Some people report that Manga is crashy unless one wipes the cache files that it immediately recreates…
You’d have thought, with a half gigabyte (and growing) cache that I’d have spotted it. But, no such problem for me.

then just subtract them – there’s no reason to do a difftime.

Ah, but what is all the rest of that code about? What’s the EOR for? Or the FP value?

I expected:

• Transfer R0 into FP register.
• Transfer R1 into FP register.
• Magical maths happens.
• Return result in FP register 0.

Instead, the difftime function seems to generate more code then its simple definition would imply.

Floating point is used elsewhere too.

Yup, anything that’s a float or double will be compiled using FP ops. It’s one of the reasons why I calculate percentages like ( (howmuch * 100) / total ) as it can all be done using straight integers.

And why are only some people seeing these problems? Why don’t I see them at all, ever?

My NewsHound logs are set to verbose, so each log only covers about 7 days. However, I also run !WimpLog, which seems to trap them. They are occasional, but sometimes a few do seem to come within a couple of days, and then a gap of weeks. The WimpLog syslog goes back nearly a year, and I show here all the entries in that time for these floating point exceptions. There were also a couple for MoreDesk, which sometimes give the error for no apparent reason other than running on the machine (an ARMX6 in this case). I hope the lines are not too long. NewsHound is running continuously and fetches every 55 mins.

26 May 15:41:56 002 80000200: Error from NewsHound: Floating point exception: invalid operation
26 May 19:21:56 002 80000200: Error from NewsHound: Floating point exception: invalid operation
27 May 18:18:57 002 80000200: Error from NewsHound: Floating point exception: invalid operation
28 May 14:59:00 002 80000200: Error from NewsHound: Floating point exception: invalid operation
28 May 17:43:58 002 80000200: Error from NewsHound: Floating point exception: invalid operation
29 May 13:41:36 002 80000200: Error from NewsHound: Floating point exception: invalid operation
10 Jun 15:00:23 002 80000200: Error from NewsHound: Floating point exception: invalid operation
30 Aug 20:41:13 002 80000200: Error from NewsHound: Floating point exception: invalid operation
02 Sep 15:52:39 002 6C43202E: MoreDesk: Floating point exception: invalid operation (1846). Click CANCEL to quit
15 Jan 23:27:29 002 6C43202E: MoreDesk: Floating point exception: invalid operation (1846). Click CANCEL to quit
16 Jan 14:27:39 002 80000200: Error from NewsHound: Floating point exception: invalid operation
16 Jan 16:17:39 002 80000200: Error from NewsHound: Floating point exception: invalid operation
16 Jan 18:07:39 002 80000020: Error from NewsHound: Divide by zero
16 Jan 19:57:44 002 80000200: Error from NewsHound: Floating point exception: invalid operation
17 Jan 14:52:42 002 80000200: Error from NewsHound: Floating point exception: invalid operation
18 Jan 16:53:53 002 80000200: Error from NewsHound: Floating point exception: invalid operation
18 Jan 23:18:40 002 80000200: Error from NewsHound: Floating point exception: invalid operation

I do get similar unexplained errors on my other hardware, none of which run NewsHound.

If its from 10 years ago and there could be all sorts of dogginess on recent machines. […] many due to bodged 32 bit conversions i.e. put a 32 bit header on the file, and just leave all the 26 bit only code as is.

I’m fairly sure that the one from 10 years ago was built from source along with the libraries using whatever version of Norcroft was current at the time, although it would have had whatever flags are in the Makefile that Dave’s reported. It wasn’t a hacked job, as it was actually a bug fix/feature enhancement exercise rather than a 32-bitting.

It wasn’t a hacked job, as it was actually a bug fix/feature enhancement exercise rather than a 32-bitting.

Every set of bug fixing is a chance to see the bugs in the next layer down :(

I’m fairly sure that the one from 10 years ago was built from source along with the libraries using whatever version of Norcroft was current at the time, although it would have had whatever flags are in the Makefile that Dave’s reported. It wasn’t a hacked job, as it was actually a bug fix/feature enhancement exercise rather than a 32-bitting.

Sorry didn’t mean to imply it was, just giving a general example. A more specific example is the recent crashes of GraphTask on the Pi4, and that copy was recompiled from source with 32 bit flags in 2009. My own copy with created with compiler from around 2013 didn’t have the problem, and the one on the website now uses DDE28. I’ve since upgraded to DD30.

Hmm – not a problem in CLib then?

Is there a reason that we can’t have Function / Procedure names for the CLib?

I did think it would be handy for Druck like util – to latch in to C Progs startup – and report CLib calls.

I suspect symbol names were stripped from the Shared C Library to reduce it’s size when included in ROM, but a RAM based version wouldn’t have to worry about that.

ARMalyser can annotate calls to SCL functions, as they are jumps trough a table set up by the SCL initialisation SWIs. However this isn’t the same thing, when a programs crashes within the SCL, you want to be able to see the names of its internal functions, not just the name of the entry point.

Does wimpclib preserve FP status register over Wimp_Poll or get the Wimp to do this for it? Edit: if it’s doing it itself, the task might get a f.p. exception delivered to it from an outstanding async exception.

Might be an idea to include function names in the SCL on all ROM builds other than IOMD.

Isn’t specifying -apcs …/nofpr incompatible with the SCL? Edit: Not at all – see below.

Might be an idea to include function names in the SCL on all ROM builds other than IOMD.

+1

What do I need to fiddle to bake this into my own ROM, as this is sufficiently useful that it ought to be done ASAP.
[I’ve already done it with my version of DeskLib, if anybody uses that…]

If CModule is used in the makefile

override C_NO_FNAMES :=

in the makefile before include CModule should do the trick.

Isn’t specifying -apcs …/nofpr incompatible with the SCL?

Are you asking me, or are you telling me?

But… if it is incompatible, shouldn’t all NewsHound users see floating point exceptions, every fetch?

I don’t know, and I don’t know where to look up the answer.

It does remind me of a discussion that we had many years ago with the Technical Publications guys where I used to work. Their manuals used to say what you could choose, but gave no guidance as to what you should choose, or why you should choose something. The Acorn C/C++ manual section about the command line options seems to me rather like that. (Tech Pubs agreed with us and changed the approach of their manuals.)

Just a thought, probably wrong; has Newshound set the bit to preserve FP registers over a Wimp_Poll?

Are you asking me, or are you telling me?

It appears to be OK to use -apcs 3/…/nofpr so long as you are consistent with it in your application and library builds and DO NOT call any C library function that expects floating point arguments, as /nofpr will cause FP values to be passed in ARM registers, but the standard C library code is compiled to expect values in FP registers. I guess that unlike /noswst, there isn’t an AOF area attribute that the linker can check as /nofpr can be valid in this case, but having code compiled with /noswst calling code compiled with /swst is a NO NO.

Edit: Sorry for the red herring, it’s actually the other way round – the procedure call standards that have been used specify nofpr, and object code symbols (not areas) do have an attribute specifying fpr / nofpr so that you would get a linker warning mixing fpr and nofpr.

How such a simple looking function turns into that….makes my head hurt.

That’s because here time_t is unsigned int, and ARM FP only has an instruction to convert signed int to double, so magic is needed…

Consider a time_t value of 0×7FFFFFFFU (2147483647, 2^31-1): it first EORS the sign bit, giving 0xFFFFFFFF (-1), floats that (-1), adds 2147483648.0 (2.0^31) giving 2147483647.0 (2.0^31-1.0)

Rick – how did it go adding Function names to the CLib?

It’s been sunny. I’ve been hacking trees, planting potatoes, washing car, traumatising cats, writing blog posts in the sunshine…

This one is on my “TODO” list. It’s a rather long list. :-/

planting potatoes

In buckets or pipes?

In trenches. https://heyrick.eu/blog/index.php?diary=20210416

They’re all Bintje. The Charlottes are taking their sweet time to wake up, so I’ll probably do those in a plastic bin or something…

Replies to Aldershot because I’m not sure that Community Support quite extends to horticulture. ;-)

Edit: Sorry for the red herring, it’s actually the other way round – the procedure call standards that have been used specify nofpr, and object code symbols (not areas) do have an attribute specifying fpr / nofpr so that you would get a linker warning mixing fpr and nofpr.

I don’t know when you edited that, but I’ve only just noticed tonight.

I changed the makefile from /nofpr to /fpr a few days ago, and the code built without a warning, which would appear to be contrary to what you wrote. I just rebuilt it to confirm. There is no error or warning using /fpr. Previously it was built (sometimes from clean, of course) with /nofpr. No warning or error there either.

It opens up a slightly bigger question of what the compiler flags should be. I looked at the examples that come with the DDE, and none of them seems to have any compiler flags at all, if I’ve looked in the right places. So do I need to pass any -apcs flags to the compiler (DDE30), or are the defaults correct for an “all known platforms” build? Same question for the “-cpu 3” and “memaccess…” flags. I’d like to go for the simplest possible solution.

Perhaps the C Tools email address would be the best way to get an answer on this one. I would be interested too, as the C compiler flags in our Makefiles probably have all sorts of unnecessary rubbish in them. For example:

CCflags = -c -depend !Depend -IC: -throwback -c99 -APCS 3/32bit/fpe2/swst/fp/nofpr -zpq40

I think the -zpq40 was to turn off a couple of compiler optimisations that were causing us grief because of compiler bugs that have probably now been fixed.

Of the APCS options, the 3/32bit is clearly right. I’ve no idea of the relative merits of fpe2 and fpe3, though the manual supplied with DDE30a says that fpe3 is now the default. I do not know whether swst and fp are the correct options to use.

You experimented with fpr instead of npfpr, but that was after you had removed all the floating point code from your application. I find it hard to imagine that there could be a choice over some of these options. The Shared C Library must surely either require floating point arguments in floating point registers (fpr), or not (nofpr). It can’t support both, can it?

The 1994 printed C/C++ manual explains the -apcs options on page 43 but does not state what the defaults are. The latest PDF supplied with DDE30a has the same information on page 45, and states the defaults for two of the options but not the others!

I suspect that the options I am using were recommended for 32 bit code for use with older versions of the compiler where the defaults had not been updated. You’d probably be safest just going for the defaults now, but it would be nice if the docs could say a bit more about this!

I agree with the above, ignore instructions aimed at old (pre Castle and ROOL) compilers, and use the default options. This will give the maximum degree of compatibility with other things built with the same compiler. Only use flags if you are deliberately doing something special, and in that case make sure everything you link to has been built with the same (or at least a compatible set of) flags.