Re: [Rpcemu] Patch to improve IOMD timer behaviour

Hi Matthew,

On Tue, 24 Jan 2023, Matthew Howkins wrote:

> Apologies for the slow response.
>
> The code looks good, but I'd like to do some further testing.

No problem.

> Do you have suggestions for programs which would benefit from these more accurate timers?

Nothing specific - I guess one of the reasons why the current
implementation has survived as long as it has is because not much code is
affected by the accuracy of the timers. But I can see that the timers are
used by:

* The Internet module for generating TCP sequence numbers (so might cause
problems in high-traffic situations?)
* ADFS for implementing many short delays (so might cause clock drift
issues during heavy disc IO?)
* And in a few other areas in the OS for generating high-resolution
timestamps (but probably not frequently enough for the current
implementation to cause serious problems)
* The gmon profiler in GCC's UnixLib

> Also, I'm aware that there's an intention to introduce an API for high-resolution timers to RISC OS,
> but I haven't been following this closely enough. Can you provide any update on the current state of
> this?

The first stage is nearing completion; I've got drivers ready for all of
the platforms ROOL offer ROM downloads for, and the kernel changes are
mostly complete. The main things holding the changes back from being
merged are the pending RISC OS 5.30 release (I think the changes are too
risky to go in to that), and finalising what the SWI names & details.

This draft MR has more info:
https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/merge_requests/63

There's some IOMD-specific test code in
https://gitlab.riscosopen.org/jlee/HAL_IOMD/-/tree/NanoTime/test/timers.
The timeloss test is the most important one - it checks that my crazy plan
for accurately scheduling interrupts for arbitrary times will actually
work.

* On real hardware it looks like it should work well enough. The time will
drift a bit, but it should be safely within the limits of the OS's current
clock correction system. The comments at the start of the file have some
example figures from real systems.
* On current versions of RPCEmu, the timeloss test appears to fail
completely - it just sits there forever without completing (I'm sure that
an earlier version of the code did complete, producing nonsense results,
but I'm not sure if I have a copy of that version any more).
* With my RPCEmu patches applied, the code runs and produces OK-ish
results. The "delta-per-event" is a bit on the large size (I've seen
around -0.37 ticks), but that's not much worse than a StrongARM with the
cache off, so it's probably fine. However the "Max time in critical
section" value can be a fair bit larger than on real machines (I've seen
it report up to 155 ticks), which may cause some problems, so I'll have to
do some more investigation around that. I'm not expecting this to be
something that could be fixed in RPCEmu (RPCEmu has no control over the
host OS's thread scheduling), so worst-case scenario might be that the
IOMD version of RISC OS 5 only offers a subset of the functionality that
the other platforms will offer (e.g. OS_ReadMonotonicTime64 available, but
the nanosecond-resolution version of OS_CallAt/OS_CallEvery unavailable)

Cheers,

- Jeffrey


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Patch to improve IOMD timer behaviour

On Fri, 30 Dec 2022 at 17:58, Jeffrey Lee <me@phlamethrower.co.uk> wrote:

Hi,

While working on some potential changes to the way RISC OS 5 uses the IOMD
timers, I spotted a couple of problems with the way RPCEmu emulates the
timers:

1. Reading from a timer can cause that timer to increment, causing it to
(a) go out of sync with the other timer, and (b) run much faster than real
time if you read from it in a loop

2. Under normal use, timers only increment in chunks of 4000 ticks,
limiting their usefulness (e.g. when latching & reading the counter to
time short sections of code or create a delay loop)

This patch should fix those two issues, by having the code get the current
time (from the QElapsedTimer) and process any pending ticks for both
timers whenever either of their GO or LAT registers are written.
gentimerirq() has also been updated so that it will use the QElapsedTimer
to work out how many ticks to apply instead of always applying 4000 ticks.

Obviously there are still improvements that could be made (e.g. more
precise timing of interrupts, synchronisation with other clocks in the
system), but this feels like a good step in the right direction. It's
enough to keep my code happy, and passes my quick "does it boot to
desktop" smoke test on various RISC OS 3.5 - 6 ROMs.

Let me know what you think!

Apologies for the slow response.

The code looks good, but I'd like to do some further testing.

Do you have suggestions for programs which would benefit from these more accurate timers?

Also, I'm aware that there's an intention to introduce an API for high-resolution timers to RISC OS, but I haven't been following this closely enough. Can you provide any update on the current state of this?

Thanks

Matthew

Re: [gccsdk] riscos.info outage (2)

On Jan 24 2023, at 5:12 am, Ron <ronanon@zoho.com> wrote:

> My last message may have only just been received.
> Since the second outage, the svn server is back to normal.
> Ronald.

Hi Ron,

I heard nothing about planned outages, and it seems the riscos.info
server did not reboot or anything. So I suppose there must have been
networking issues somewhere that meant it was unrouteable for a while.

In future, if the server is completely unavailable the mailing lists
also won't work - please email me on riscos.info at markettos.org.uk in
that instance to let me know.

Thanks
Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] no tabs in a program compiled with GCC 4.7.4 release 6 with -mlibscl option

Thank you, Lee, for getting back to me. 

On Sun, 8 Jan 2023, 16:26 Lee Noar, <lee.noar@sky.com> wrote:

Do you mean that the output from printf doesn't produce tabs, e.g.,

printf("\t\tABC\n");

shows ABC against the left most edge with no white space?

Yes, it doesn't produce TABS.

On revisiting this and using your example, I discovered that linking to the library (libscl) seems to output two spaces rather than the expected TABS.

> Is it a bug with other side effects? Or expected behaviour?

Well, -mlibscl links against the SharedCLibrary, so it would be the
printf there that is responsible. Whether it's intended behaviour,
I'm not sure.

I have tried different ROMS back to 5.28, and the issue is there, so perhaps it is what it is.

I was wondering whether or not reporting it to ROOL. My gut feeling is that it's probably best to accept that it's a feature when linking to that particular library using GCC.

All the best,

Andrew.

Re: [gccsdk] SOMRun leaves stale DDEUtils command line

On 20/08/2022 15:00, Andrew McCarthy wrote:
> Hello,
>
> For information, for anyone with interest.
>
> There's a thread about SOMRun on the ROOL forum ->
> https://www.riscosopen.org/forum/forums/4/topics/17439#posts-134454
> <https://www.riscosopen.org/forum/forums/4/topics/17439#posts-134454>

This should now be fixed with r7735. It turned out to be an issue with
the dynamic linker rather than SOManager.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] SOMRun leaves stale DDEUtils command line

On 20/08/2022 15:00, Andrew McCarthy wrote:
> Hello,
>
> For information, for anyone with interest.
>
> There's a thread about SOMRun on the ROOL forum ->
> https://www.riscosopen.org/forum/forums/4/topics/17439#posts-134454
> <https://www.riscosopen.org/forum/forums/4/topics/17439#posts-134454>

OK, I did see this post at the time...then I forgot, oops, sorry about
that. So, now that I've rediscovered it, I'll take a look.

Thanks,
Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] no tabs in a program compiled with GCC 4.7.4 release 6 with -mlibscl option

On 08/01/2023 15:18, Andrew McCarthy wrote:
> An observation I made when running GCC 4.7.4. release 6 with the
> -mlibscl option used is that no tab spacing (\t) is present in the
> compiled program, which leaves me wondering if it is a bug or not. It
> doesn't matter whether I double-click or run the program from the task
> window; there is no tab spacing in the output.
>
> In contrast, when I compile with -static and elf2aif, the tabs are there.

Do you mean that the output from printf doesn't produce tabs, e.g.,

printf("\t\tABC\n");

shows ABC against the left most edge with no white space? How about
if you redirect output to a file?

> Is it a bug with other side effects? Or expected behaviour?

Well, -mlibscl links against the SharedCLibrary, so it would be the
printf there that is responsible. Whether it's intended behaviour,
I'm not sure.

Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] no tabs in a program compiled with GCC 4.7.4 release 6 with -mlibscl option

An observation I made when running GCC 4.7.4. release 6 with the -mlibscl option used is that no tab spacing (\t) is present in the compiled program, which leaves me wondering if it is a bug or not. It doesn't matter whether I double-click or run the program from the task window; there is no tab spacing in the output.

In contrast, when I compile with -static and elf2aif, the tabs are there.

Is it a bug with other side effects? Or expected behaviour?

All the best,

Andrew