Are there any standard header files supplied as part of the GCCSDK for
defining SWI names in Asasm? I've had a grep around the GCCSDK folders, but
can't see anything obvious.
They're not too hard to make, but if something already exists there's little
point duplicating effort.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
_______________________________________________
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
Saturday, 26 September 2020
Friday, 25 September 2020
Re: [Rpcemu] Installing to Linux
In article
<CANc9Z=wueKQ8XJ95mGVQkq-gzdLAWpQ9ZN+N8Le=R4r67mf3rQ@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, 10 May 2020 at 21:40, Andrew Hodgkinson
> <ahodgkin@riscosopen.org> wrote:
> > On 11 May 2020, at 2:25, John McCartney wrote:
> >
> > [...] interpreter or the dynamic recompiler [...]
> > What's the difference and on what basis should I base
> > my decision?
> >
> > The interpreter is slow but accurate, treating each ARM
> > instruction sequence it encounters as if it were the
> > for first time and translating them over and over. The
> > recompiler tries to remember previously converted
> > sequences, which increases speed a great deal but
> > because of the complexities of CPUs and the
> > recompilation process, this can reduce emulation
> > accuracy and cause problems with some pieces of
> > software.
> >
> > I recommend you build both. Use the recompiler version
> > normally, but if you encounter crashes you wouldn't
> > expect from a normal RISC OS machine, switch to the
> > interpreter version.
I'm sorry I didn't reply to this at the time, Andrew, but
thanks for the explanation. Also, in reply to my post on 28
May, you suggested that rpcemu-recompiler might not have
been set as an executable; in fact it had been.
> A bit more info here; I'll try to remember to update the
> compile pages to link to what the different builds are.
> The most important thing is to report as bugs things that
> don't work in the recompiler but do in the interpreter,
> it's not that the recompiler *can't* be as accurate, it's
> just that it isn't. Unreported bugs are much less likely
> to get fixed.
Another apology for my lack of a reply. I'm aware that bugs
can't be fixed unless they're reported and I'll certainly
do so if and when I find any. However, I'm hardly a power
user and so might not come across (m)any bugs at all.
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CANc9Z=wueKQ8XJ95mGVQkq-gzdLAWpQ9ZN+N8Le=R4r67mf3rQ@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, 10 May 2020 at 21:40, Andrew Hodgkinson
> <ahodgkin@riscosopen.org> wrote:
> > On 11 May 2020, at 2:25, John McCartney wrote:
> >
> > [...] interpreter or the dynamic recompiler [...]
> > What's the difference and on what basis should I base
> > my decision?
> >
> > The interpreter is slow but accurate, treating each ARM
> > instruction sequence it encounters as if it were the
> > for first time and translating them over and over. The
> > recompiler tries to remember previously converted
> > sequences, which increases speed a great deal but
> > because of the complexities of CPUs and the
> > recompilation process, this can reduce emulation
> > accuracy and cause problems with some pieces of
> > software.
> >
> > I recommend you build both. Use the recompiler version
> > normally, but if you encounter crashes you wouldn't
> > expect from a normal RISC OS machine, switch to the
> > interpreter version.
I'm sorry I didn't reply to this at the time, Andrew, but
thanks for the explanation. Also, in reply to my post on 28
May, you suggested that rpcemu-recompiler might not have
been set as an executable; in fact it had been.
> A bit more info here; I'll try to remember to update the
> compile pages to link to what the different builds are.
> The most important thing is to report as bugs things that
> don't work in the recompiler but do in the interpreter,
> it's not that the recompiler *can't* be as accurate, it's
> just that it isn't. Unreported bugs are much less likely
> to get fixed.
Another apology for my lack of a reply. I'm aware that bugs
can't be fixed unless they're reported and I'll certainly
do so if and when I find any. However, I'm hardly a power
user and so might not come across (m)any bugs at all.
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Installing to Linux (John McCartney)
This post and one in another thread are both triggered by
my intention to install RPCEmu on a laptop. Originally, I
installed it on my desktop Linux PC which gave rise to my
queries in this thread.
In article <5878ae9aedj.mccartney@blueyonder.co.uk>,
I <j.mccartney@blueyonder.co.uk> wrote:
> Just a quickie to acknowledge all those who've offered
> advice on this thread. I'm going to have to park it for a
> few days because I have other calls on my limited time at
> the moment.
Well, it's only a few days since May. Or have I missed
something?
Originally, to run RPCEmu, I had used the following lines
in the terminal:
cd rpcemu-0.9.3
./rpcemu-recompiler
After my request for help (and being timid and not having
dealt with scripts before) I put them into a text file and
copied and pasted them into the terminal and hit enter.
As my sophistication grew(!!!) I added a return to the text
so that I didn't have to hit enter.
It all worked but I got fed up with c&p so I today I looked
again at the suggestions I was given.
Brian's method worked when the script was in the
rpcemu-0.9.3 directory but creating a link and putting it
on the desktop failed. No doubt my limited knowledge of
Linux has let me down here.
Jim's and Peter's suggestions were very similar though I
don't know what the significance is between their two first
lines: Jim's ends in /sh and Peter's in /bash -
again, my lack of knowledge is letting me down.
I've ended up using the following:
#!/bin/bash
cd /home/john/rpcemu-0.9.3
./rpcemu-recompiler
This works but, having changed the file permissions to make
it executable, I have to select Run from the resulting four
options after double-clicking on the file on the desktop.
Is it possible to make it RPCEmu run from just a double
click on the file?
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
my intention to install RPCEmu on a laptop. Originally, I
installed it on my desktop Linux PC which gave rise to my
queries in this thread.
In article <5878ae9aedj.mccartney@blueyonder.co.uk>,
I <j.mccartney@blueyonder.co.uk> wrote:
> Just a quickie to acknowledge all those who've offered
> advice on this thread. I'm going to have to park it for a
> few days because I have other calls on my limited time at
> the moment.
Well, it's only a few days since May. Or have I missed
something?
Originally, to run RPCEmu, I had used the following lines
in the terminal:
cd rpcemu-0.9.3
./rpcemu-recompiler
After my request for help (and being timid and not having
dealt with scripts before) I put them into a text file and
copied and pasted them into the terminal and hit enter.
As my sophistication grew(!!!) I added a return to the text
so that I didn't have to hit enter.
It all worked but I got fed up with c&p so I today I looked
again at the suggestions I was given.
Brian's method worked when the script was in the
rpcemu-0.9.3 directory but creating a link and putting it
on the desktop failed. No doubt my limited knowledge of
Linux has let me down here.
Jim's and Peter's suggestions were very similar though I
don't know what the significance is between their two first
lines: Jim's ends in /sh and Peter's in /bash -
again, my lack of knowledge is letting me down.
I've ended up using the following:
#!/bin/bash
cd /home/john/rpcemu-0.9.3
./rpcemu-recompiler
This works but, having changed the file permissions to make
it executable, I have to select Run from the resulting four
options after double-clicking on the file on the desktop.
Is it possible to make it RPCEmu run from just a double
click on the file?
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 22 September 2020
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 2020-09-22 at 19:02 +0100, Peter Howkins wrote:
> On Tue, 22 Sep 2020 at 18:08, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> > > On Tue, 22 Sep 2020 at 16:17, Steven Newbury <
> > steve@snewbury.org.uk>
> > > wrote:
> > > > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > > > I thought I'd add RPCEmu to my Gentoo overlay, but given it
> > only
> > > > > supports a hard-coded data path it doesn't lend itself to
> > > > packaging
> > > > > for
> > > > > system-wide installation on *NIX. So I've added support for
> > > > multiple
> > > > > search directories and XDG-BaseDir through libxdg-basedir.
> > > > >
> > > > Just noticed I didn't finish removing the fixed stack allocated
> > > > filename buffers. Probably not the only issues. Please let me
> > > > know if
> > > > there's anything else to fix.
> > >
> > > Hello Steven, I'm afraid there are fundamental issues with this
> > that
> > > means I'm not interested in merging this approach, or any derived
> > > from it at this point.
> > >
> > Anything specific?
>
> If I'm reading it right
>
> 1) You can no longer run more than one copy of RPCEmu using different
> settings
You can use XDG_DATA_HOME to override the datadir, use multiple copies
with a different path. See:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
> 2) You're using XDG data directories that include system paths for
> things. This breaks horribly on multi-user systems, users shouldn't
> be sharing logs, config files, ide discs, hostfs, cmos files. About
> the only thing that could theoretically be shared is the ROM, as it's
> read-only, but as it's only one thing I can live with that also being
> a per-user-per-configuration thing.
That's exactly what XDG-Basedir is for. You can have system-wide
default config, roms etc, but any user settings override them, and
settings/resources are always saved to the local store. See spec
above.
> 3) You broke windows and macos (but that's a relatively small fix up)
Yes, I realised that, but it isn't easy for me to test, especially
macos. Multiple search paths should work there too I would have
thought.
> 4) By allowing the related config and files for a machine to be
> stored in separate directories on a system you lose the ability to
> keep them grouped for future multi-machine aware rpcemu (admittedly
> you wouldn't have been aware of that).
If I understand, you mean a group of directories for rom/disk/cmos etc
for a RiscPC vs A7000 in separate directorys one level up? Or
something else?
..
As an aside, I have to say RPCEmu is pretty awesome. It makes me want
to dig out my old hard disk from my StrongARM RiscPC, could even
resurrect some of my old RISC OS projects if I can find it and it still
works...
I actually had a support request for a free software application I
released back then a few years ago but couldn't help since my RiscPC
was broken!
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Tue, 22 Sep 2020 at 18:08, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> > > On Tue, 22 Sep 2020 at 16:17, Steven Newbury <
> > steve@snewbury.org.uk>
> > > wrote:
> > > > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > > > I thought I'd add RPCEmu to my Gentoo overlay, but given it
> > only
> > > > > supports a hard-coded data path it doesn't lend itself to
> > > > packaging
> > > > > for
> > > > > system-wide installation on *NIX. So I've added support for
> > > > multiple
> > > > > search directories and XDG-BaseDir through libxdg-basedir.
> > > > >
> > > > Just noticed I didn't finish removing the fixed stack allocated
> > > > filename buffers. Probably not the only issues. Please let me
> > > > know if
> > > > there's anything else to fix.
> > >
> > > Hello Steven, I'm afraid there are fundamental issues with this
> > that
> > > means I'm not interested in merging this approach, or any derived
> > > from it at this point.
> > >
> > Anything specific?
>
> If I'm reading it right
>
> 1) You can no longer run more than one copy of RPCEmu using different
> settings
You can use XDG_DATA_HOME to override the datadir, use multiple copies
with a different path. See:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
> 2) You're using XDG data directories that include system paths for
> things. This breaks horribly on multi-user systems, users shouldn't
> be sharing logs, config files, ide discs, hostfs, cmos files. About
> the only thing that could theoretically be shared is the ROM, as it's
> read-only, but as it's only one thing I can live with that also being
> a per-user-per-configuration thing.
That's exactly what XDG-Basedir is for. You can have system-wide
default config, roms etc, but any user settings override them, and
settings/resources are always saved to the local store. See spec
above.
> 3) You broke windows and macos (but that's a relatively small fix up)
Yes, I realised that, but it isn't easy for me to test, especially
macos. Multiple search paths should work there too I would have
thought.
> 4) By allowing the related config and files for a machine to be
> stored in separate directories on a system you lose the ability to
> keep them grouped for future multi-machine aware rpcemu (admittedly
> you wouldn't have been aware of that).
If I understand, you mean a group of directories for rom/disk/cmos etc
for a RiscPC vs A7000 in separate directorys one level up? Or
something else?
..
As an aside, I have to say RPCEmu is pretty awesome. It makes me want
to dig out my old hard disk from my StrongARM RiscPC, could even
resurrect some of my old RISC OS projects if I can find it and it still
works...
I actually had a support request for a free software application I
released back then a few years ago but couldn't help since my RiscPC
was broken!
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 22 Sep 2020 at 18:08, Steven Newbury <steve@snewbury.org.uk> wrote:
On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > supports a hard-coded data path it doesn't lend itself to
> > packaging
> > > for
> > > system-wide installation on *NIX. So I've added support for
> > multiple
> > > search directories and XDG-BaseDir through libxdg-basedir.
> > >
> > Just noticed I didn't finish removing the fixed stack allocated
> > filename buffers. Probably not the only issues. Please let me
> > know if
> > there's anything else to fix.
>
> Hello Steven, I'm afraid there are fundamental issues with this that
> means I'm not interested in merging this approach, or any derived
> from it at this point.
>
Anything specific?
If I'm reading it right
1) You can no longer run more than one copy of RPCEmu using different settings
2) You're using XDG data directories that include system paths for things. This breaks horribly on multi-user systems, users shouldn't be sharing logs, config files, ide discs, hostfs, cmos files. About the only thing that could theoretically be shared is the ROM, as it's read-only, but as it's only one thing I can live with that also being a per-user-per-configuration thing.
3) You broke windows and macos (but that's a relatively small fix up)
4) By allowing the related config and files for a machine to be stored in separate directories on a system you lose the ability to keep them grouped for future multi-machine aware rpcemu (admittedly you wouldn't have been aware of that).
Peter
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > supports a hard-coded data path it doesn't lend itself to
> > packaging
> > > for
> > > system-wide installation on *NIX. So I've added support for
> > multiple
> > > search directories and XDG-BaseDir through libxdg-basedir.
> > >
> > Just noticed I didn't finish removing the fixed stack allocated
> > filename buffers. Probably not the only issues. Please let me
> > know if
> > there's anything else to fix.
>
> Hello Steven, I'm afraid there are fundamental issues with this that
> means I'm not interested in merging this approach, or any derived
> from it at this point.
>
Anything specific? Using XDG-BaseDir is the Standard approach to
solving this on Linux. I deliberately kept that code in rpc-machdep-
xdg.c, and just expanded the the file handling in the generic code to
accomodate multiple paths, while making sure it still worked as before
if only "./" exists. There is support also in qt5, but that would mean
using qt outside of the GUI support code, which would mean C++.
> There are many issues that need to be resolved for systemwide install
> on multiple platforms and your method actually adds more problems
> than it solves.
It works for me. What are the systemwide install issues? I'm happy to
look at them since I'm quite familiar with the code now after hacking
on this for a couple of days.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk>
> wrote:
> > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > supports a hard-coded data path it doesn't lend itself to
> > packaging
> > > for
> > > system-wide installation on *NIX. So I've added support for
> > multiple
> > > search directories and XDG-BaseDir through libxdg-basedir.
> > >
> > Just noticed I didn't finish removing the fixed stack allocated
> > filename buffers. Probably not the only issues. Please let me
> > know if
> > there's anything else to fix.
>
> Hello Steven, I'm afraid there are fundamental issues with this that
> means I'm not interested in merging this approach, or any derived
> from it at this point.
>
Anything specific? Using XDG-BaseDir is the Standard approach to
solving this on Linux. I deliberately kept that code in rpc-machdep-
xdg.c, and just expanded the the file handling in the generic code to
accomodate multiple paths, while making sure it still worked as before
if only "./" exists. There is support also in qt5, but that would mean
using qt outside of the GUI support code, which would mean C++.
> There are many issues that need to be resolved for systemwide install
> on multiple platforms and your method actually adds more problems
> than it solves.
It works for me. What are the systemwide install issues? I'm happy to
look at them since I'm quite familiar with the code now after hacking
on this for a couple of days.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support
On Tue, 22 Sep 2020 at 16:17, Steven Newbury <steve@snewbury.org.uk> wrote:
On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> supports a hard-coded data path it doesn't lend itself to packaging
> for
> system-wide installation on *NIX. So I've added support for multiple
> search directories and XDG-BaseDir through libxdg-basedir.
>
Just noticed I didn't finish removing the fixed stack allocated
filename buffers. Probably not the only issues. Please let me know if
there's anything else to fix.
Hello Steven, I'm afraid there are fundamental issues with this that means I'm not interested in merging this approach, or any derived from it at this point.
There are many issues that need to be resolved for systemwide install on multiple platforms and your method actually adds more problems than it solves.
Peter
Subscribe to:
Posts (Atom)