Claim_ASWI
Owain Cole
RiscOS3.5??+
Can anybody e-mail me the docs on it (and relaseSWI) because I can't find
any info on it at all!
Cheers,
Owain.
VotI
Dickon Hood
Owain Cole <es...@csv.warwick.ac.uk> wrote:
: Or whatever that SWI is called, the one that allows you to grab a SWI in
: RiscOS3.5??+
: Can anybody e-mail me the docs on it (and relaseSWI) because I can't find
: any info on it at all!
OS_CallASWI. SWI number in r10, other regs. as per SWI.
OS_CallASWIR12. SWI number in r12, other regs. as per SWI.
You didn't look that hard...
--
Dickon Hood
Due to binaries posted to non-binary newsgroups, my .sig is
temporarily unavailable. Normal service will be resumed as soon as
possible. We apologise for the inconvenience in the mean time.
Barry Wickett
<URL:mailto:dicko...@fluff.org> wrote:
> In message <Pine.GSO.4.05.990505...@mimosa.csv.warwick.ac.uk>
> Owain Cole <es...@csv.warwick.ac.uk> wrote:
>
> : Or whatever that SWI is called, the one that allows you to grab a SWI in
> : RiscOS3.5??+
>
> : Can anybody e-mail me the docs on it (and relaseSWI) because I can't find
> : any info on it at all!
>
> OS_CallASWI. SWI number in r10, other regs. as per SWI.
>
> OS_CallASWIR12. SWI number in r12, other regs. as per SWI.
>
> You didn't look that hard...
>
Does this actually /claim/ it though or merely /call/ it?
Barry
Dickon Hood
Barry Wickett <Ba...@tquest.org.uk> wrote:
: In article <992768fd48%dicko...@splurge.fluff.org>, Dickon Hood
: <URL:mailto:dicko...@fluff.org> wrote:
Mmm, good point. My mistake. Ignore that.
Matthias Seifert
> Or whatever that SWI is called, the one that allows you to grab a SWI in
> RiscOS3.5??+
> Can anybody e-mail me the docs on it (and relaseSWI) because I can't find
> any info on it at all!
There is a SWI named "OS_ClaimSWI" (and "OS_ReleaseSWI") but they do not
work, as I have been told by Acorn years ago. They said that they planned
to do these SWIs but then decided not to do it (I don't know why, maybe
performance reasons).
--
_ _ | Acorn Risc PC, StrongARM @ 287 MHz
| | | _, _|__|_ |) ' _, , | 130 Mbyte RAM, ~30 Gbyte HD
| | | / | | | |/\ | / | / \ | ------------------------------------
| | |_/\/|_/|_/|_/| |/|/\/|_/ \/ | http://www.deutschlandwetter.de
Paul Corke
> Owain Cole <es...@csv.warwick.ac.uk> wrote:
> > Or whatever that SWI is called, the one that allows you to grab a SWI in
> > RiscOS3.5??+
I think you mean OS_ClaimProcessorVector(&69) [5-46].
You really need to know what you're doing if you use this - when the SWI
happens, you will be called with no environment (eg don't trust r13) and
IIRC you'll be in a 32bit code mode.
Paul.
--
Interconnex UK Ltd
Box Bush Farm, West Wick, W-s-M, BS24 7TF. Tel & Fax: (01934) 522880.
mailto:pa...@interconnex.co.uk http://www.interconnex.co.uk/
Piers Wombwell
<URL:mailto:M.Se...@t-online.de> wrote:
> Owain Cole <es...@csv.warwick.ac.uk> wrote:
> > Or whatever that SWI is called, the one that allows you to grab a SWI in
> > RiscOS3.5??+
>
> > any info on it at all!
>
> There is a SWI named "OS_ClaimSWI" (and "OS_ReleaseSWI") but they do not
> work, as I have been told by Acorn years ago. They said that they planned
> to do these SWIs but then decided not to do it (I don't know why, maybe
> performance reasons).
ISTR DDT adds these SWIs...
Anyway, you can use OS_ClaimProcessorVector on RO3.5 or later. It's not
recommended, though, as it causes all SWIs to be slower. You must also
deregister the claimants in the order they were claimed.
I *think* you're entered in 32-bit mode - you'll have to check.
p.
Stewart Brodie
malcolm <mal...@armage.demon.co.uk> wrote:
> In message <Pine.GSO.4.05.990505...@mimosa.csv.warwick.ac.uk>
> Owain Cole <es...@csv.warwick.ac.uk> wrote:
>
> > Or whatever that SWI is called, the one that allows you to grab a SWI in
> > RiscOS3.5??+
> >
> > Can anybody e-mail me the docs on it (and relaseSWI) because I can't find
> > any info on it at all!
>
> If there is a such a thing, it is just what I need! At present I am
> planning to use wimp_SWIve to intercept calls to the wimp but that is a
> bit of a fudge and a safer, more general way to intercept SWI calls
> would be preferable.
The SWI is only to be found in the OS SWI name decoding tables. The dispatch
table entries for these two SWIs just cause a No such SWI error if you
attempt to call it, though.
It was never implemented.
(speaking personally)
--
Stewart Brodie, Software Engineer
Element 14 Ltd
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.e-14.com/
Matthias Seifert
[...]
> Anyway, you can use OS_ClaimProcessorVector on RO3.5 or later. It's not
> recommended, though, as it causes all SWIs to be slower. You must also
> deregister the claimants in the order they were claimed.
> I *think* you're entered in 32-bit mode - you'll have to check.
Yes, your code _is_ entered in 32-bit mode. And it's quite hard to get it
right from this point if you aren't used to 32-bit mode programming (as is
probably the case with most RISC OS programmes)... :-}
Richard Jozefowski
<URL:mailto:M.Se...@t-online.de> wrote:
> Piers Wombwell <pwom...@e-14.com> wrote:
>
> [...]
> > Anyway, you can use OS_ClaimProcessorVector on RO3.5 or later. It's not
> > recommended, though, as it causes all SWIs to be slower. You must also
> > deregister the claimants in the order they were claimed.
>
> > I *think* you're entered in 32-bit mode - you'll have to check.
>
> Yes, your code _is_ entered in 32-bit mode. And it's quite hard to get it
> right from this point if you aren't used to 32-bit mode programming (as is
> probably the case with most RISC OS programmes)... :-}
Is this the case with non StrongARM machines? Bear in mind the original
post concerned RISC OS 3.5.
--
Richard
Matthias Seifert
I know that you are not a programmer but your postings in the past made
(to me) the impression, that you know very well what you are talking
about. But now I'm a bit disappointed. ;-)
Of course by using the SWI "OS_ClaimProcessorVector" _all_ processors
enter your code in 32 bit mode. As this SWI has been introduced with RISC
OS 3.5 (and thus with the RiscPC, i.e. at least ARM610) it hasn't to cope
with '26-bit only processors'. :-)
Timothy Baldwin
Paul Corke <pa...@interconnex.co.uk> wrote:
> > In message <Pine.GSO.4.05.990505...@mimosa.csv.warwic
> > Owain Cole <es...@csv.warwick.ac.uk> wrote:
> > > Or whatever that SWI is called, the one that allows you to grab a SWI in
> > > RiscOS3.5??+
>
> I think you mean OS_ClaimProcessorVector(&69) [5-46].
>
> You really need to know what you're doing if you use this - when the SWI
> happens, you will be called with no environment (eg don't trust r13) and
> IIRC you'll be in a 32bit code mode.
Almost right, R13 will point the supervisor stack as usual.
--
http://www.reinhouse.freeserve.co.uk/
PGP key fingerprint = D6 FA 76 1D 68 F6 7B 96 F4 BC F2 62 D2 02 62 8E
Read the uk newsgroups? Then read uk.net.news.announce
Richard Jozefowski
> > >
> > > Yes, your code _is_ entered in 32-bit mode. And it's quite hard to get
> > > it right from this point if you aren't used to 32-bit mode programming
> > > (as is probably the case with most RISC OS programmes)... :-}
>
> > Is this the case with non StrongARM machines? Bear in mind the original
> > post concerned RISC OS 3.5.
>
> I know that you are not a programmer but your postings in the past made
> (to me) the impression, that you know very well what you are talking
> about. But now I'm a bit disappointed. ;-)
>
> Of course by using the SWI "OS_ClaimProcessorVector" _all_ processors
> enter your code in 32 bit mode. As this SWI has been introduced with RISC
> OS 3.5 (and thus with the RiscPC, i.e. at least ARM610) it hasn't to cope
> with '26-bit only processors'. :-)
I'm sorry to have disappointed you so. However, you should realise that
when I say I'm no programmer, I mean it ;-)
This is my understanding, please correct my thinking:
I'd assumed that with 3.5 (that's prior to the StrongARM I think) the ARM610
was setup to operate in 26-bit program space, 32-bit data space (bit 4 clear
and bit 5 set in internal coprocessor register 1). Unlike the StrongARM, if
the ARM610 is setup to operate in 26-bit program space it will enter
exceptions in 26-bit mode. Am I wrong, was bit 4 set?
The SA-110 StrongARM supports 26-bit mode but exceptions are always
initiated in 32 bit mode. RISC OS has some patch up code at the start of an
exception to fudge the registers (eg R15) to make it appear like a 26-bit
mode exception - it then branches into the standard 26-bit handlers.
If 3.5 ran in 32-bit mode then the patch up code must have already been
present at this stage, I thought it only came in at 3.7. I note that on 3.7
with my ARM710 (very similar to the ARM610) it goes through the patch up
code. I have not bothered to find out if it is setup to operate in 26-bit
program space. Apart from slowing exceptions down a bit, would there be any
harm for an ARM610/710 to go through the patch up code in 26-bit mode?
Perhaps I'm confusing it with APEX where the 26-bit patch up code was only
introduced on StrongARM and only gets used when a StrongARM is fitted.
--
Richard
Richard Jozefowski
>
> I'd assumed that with 3.5 (that's prior to the StrongARM I think) the ARM610
> was setup to operate in 26-bit program space, 32-bit data space (bit 4 clear
> and bit 5 set in internal coprocessor register 1). Unlike the StrongARM, if
> the ARM610 is setup to operate in 26-bit program space it will enter
> exceptions in 26-bit mode. Am I wrong, was bit 4 set?
I reckon that on 3.7 bit 4 of ARM610s is indeed set, meaning it is
configured to enter exceptions in 32-bit mode and meaning it requires the
26-bit fix up code. Tell me this was the case with 3.5 too and I'll stop
digging ;-)
--
Richard
Richard Jozefowski
> Richard Jozefowski <ric...@millipede.co.uk> wrote:
> > In article <48fe7a940...@t-online.de>, Matthias Seifert
> > >
> > > Yes, your code _is_ entered in 32-bit mode. And it's quite hard to get
> > > it right from this point if you aren't used to 32-bit mode programming
> > > (as is probably the case with most RISC OS programmes)... :-}
>
> > Is this the case with non StrongARM machines? Bear in mind the original
> > post concerned RISC OS 3.5.
>
> I know that you are not a programmer but your postings in the past made
> (to me) the impression, that you know very well what you are talking
> about. But now I'm a bit disappointed. ;-)
>
> Of course by using the SWI "OS_ClaimProcessorVector" _all_ processors
> enter your code in 32 bit mode. As this SWI has been introduced with RISC
> OS 3.5 (and thus with the RiscPC, i.e. at least ARM610) it hasn't to cope
> with '26-bit only processors'. :-)
Oh dear, yes you are quite right :-(
Even on 3.5 the ARM610s were configured to 32-bit address space (bit 4 set
in internal co-processor register 1), meaning that all exceptions entered in
32-bit mode. Hence, even on 3.5, fix up veneer code was required before
entering the 26-bit exception handlers. Getting confused with APEX I'd
thought that game only started with StrongARMs.
This should teach me not to comment on programming, especially at my age.
The old carpenter's saying "measure twice, cut once" could be paraphrased
"think twice, post once"!
--
Richard
Matthias Seifert
> > > >
> > > > Yes, your code _is_ entered in 32-bit mode. And it's quite hard to
> > > > get it right from this point if you aren't used to 32-bit mode
> > > > programming (as is probably the case with most RISC OS
> > > > programmes)... :-}
> >
> > > Is this the case with non StrongARM machines? Bear in mind the
> > > original post concerned RISC OS 3.5.
> >
> > I know that you are not a programmer but your postings in the past made
> > (to me) the impression, that you know very well what you are talking
> > about. But now I'm a bit disappointed. ;-)
> >
> > Of course by using the SWI "OS_ClaimProcessorVector" _all_ processors
> > enter your code in 32 bit mode. As this SWI has been introduced with
> > RISC OS 3.5 (and thus with the RiscPC, i.e. at least ARM610) it hasn't
> > to cope with '26-bit only processors'. :-)
> I'm sorry to have disappointed you so. However, you should realise that
> when I say I'm no programmer, I mean it ;-)
Of course you do. But what you post makes the impression that you could be
one. ;-)
> This is my understanding, please correct my thinking:
> I'd assumed that with 3.5 (that's prior to the StrongARM I think) the
> ARM610 was setup to operate in 26-bit program space, 32-bit data space
> (bit 4 clear and bit 5 set in internal coprocessor register 1). Unlike
> the StrongARM, if the ARM610 is setup to operate in 26-bit program space
> it will enter exceptions in 26-bit mode. Am I wrong, was bit 4 set?
Yes you are. Even RISC OS 3.5 set up the ARM processor (i.e. ARM610,
ARM710 or ARM700) completely to 32 bit mode. The 'trap' handlers change to
26 bit mode 'by hand'.
> The SA-110 StrongARM supports 26-bit mode but exceptions are always
> initiated in 32 bit mode. RISC OS has some patch up code at the start
> of an exception to fudge the registers (eg R15) to make it appear like a
> 26-bit mode exception - it then branches into the standard 26-bit
> handlers.
That's correct.
And you are (still) sure that you are not a programmer? ;-)
> If 3.5 ran in 32-bit mode then the patch up code must have already been
> present at this stage,
As it was. :-)
> I thought it only came in at 3.7.
Then you was wrong with this.
> I note that on 3.7 with my ARM710 (very similar to the ARM610) it goes
> through the patch up code. I have not bothered to find out if it is
> setup to operate in 26-bit program space.
It isn't.
> Apart from slowing exceptions down a bit, would there be any harm for an
> ARM610/710 to go through the patch up code in 26-bit mode?
Well, it would probably (but I'm not sure with this) not work...
> Perhaps I'm confusing it with APEX where the 26-bit patch up code was
> only introduced on StrongARM and only gets used when a StrongARM is
> fitted.
Well, this could be the case. But I only saw the APEX card once (years ago
at a German computer show where I even talked to you) and don't know how
it works internally. ;-)
Matthias Seifert
> Matthias Seifert wrote:
> > Richard Jozefowski <ric...@millipede.co.uk> wrote:
> > > In article <48fe7a940...@t-online.de>, Matthias Seifert
> > > >
> > > > Yes, your code _is_ entered in 32-bit mode. And it's quite hard to
> > > > get it right from this point if you aren't used to 32-bit mode
> > > > programming (as is probably the case with most RISC OS
> > > > programmes)... :-}
> >
> > > Is this the case with non StrongARM machines? Bear in mind the
> > > original post concerned RISC OS 3.5.
> >
> > I know that you are not a programmer but your postings in the past
> > made (to me) the impression, that you know very well what you are
> > talking about. But now I'm a bit disappointed. ;-)
> >
> > Of course by using the SWI "OS_ClaimProcessorVector" _all_ processors
> > enter your code in 32 bit mode. As this SWI has been introduced with
> > RISC OS 3.5 (and thus with the RiscPC, i.e. at least ARM610) it hasn't
> > to cope with '26-bit only processors'. :-)
> Oh dear, yes you are quite right :-(
> Even on 3.5 the ARM610s were configured to 32-bit address space (bit 4
> set in internal co-processor register 1), meaning that all exceptions
> entered in 32-bit mode. Hence, even on 3.5, fix up veneer code was
> required before entering the 26-bit exception handlers. Getting
> confused with APEX I'd thought that game only started with StrongARMs.
Well, maybe I should read you last posting first next time you post
several messages... ;-)
> This should teach me not to comment on programming, especially at my
> age. The old carpenter's saying "measure twice, cut once" could be
> paraphrased "think twice, post once"!
Well, at least it seems that you know what you are talking about - which
is not always the case in c.s.a groups... ;-D
And we all make mistakes from time to time... :-)
Matthias Seifert
> Earlier I wrote (snipped):
> >
> > I'd assumed that with 3.5 (that's prior to the StrongARM I think) the
> > ARM610 was setup to operate in 26-bit program space, 32-bit data space
> > (bit 4 clear and bit 5 set in internal coprocessor register 1).
> > Unlike the StrongARM, if the ARM610 is setup to operate in 26-bit
> > program space it will enter exceptions in 26-bit mode. Am I wrong,
> > was bit 4 set?
> I reckon that on 3.7 bit 4 of ARM610s is indeed set, meaning it is
> configured to enter exceptions in 32-bit mode and meaning it requires the
> 26-bit fix up code. Tell me this was the case with 3.5 too and I'll stop
> digging ;-)
OK, then I'm telling it: It was already the case with RISC OS 3.5. :-)
notha...@spam.com
: Anyway, you can use OS_ClaimProcessorVector on RO3.5 or later. It's not
: recommended, though, as it causes all SWIs to be slower. You must also
: deregister the claimants in the order they were claimed.
Hmm, maybe I should finish my documentation on my SimpleSWI module. This module
allows you to claim one SWI, or a range of SWI's (number+bitmask) in either
pre- or post-process mode (i.e. before the normal routines are called, or
afterwards) and the best thing is that any code that uses the SimpleSWI module
can release their claims at any time in any order.
I really couldn't be bothered to finish documentation and release it as a developer
package, although the module itself was released with RAMplify.
If there's enough demand for this module I could probably be persuaded to finish
documentation and release it. You can reach me at
pervect.topix.student.utwente.nl
^
replace this dot with an @
Cheers,
Eli-Jean
aka Pervect of Topix
rg
>Or whatever that SWI is called, the one that allows you to grab a SWI in
>RiscOS3.5??+
>Can anybody e-mail me the docs on it (and relaseSWI) because I can't find
>any info on it at all!
Wacky-Talky supports claiming *any* RO SWI with the best way, without
slowing down
the rest of the SWIs. Using WT_ClaimSWI & WT_ReleaseSWI, any SWI can be used
as a vector.
You ca find WT (Wacky-Talky) at Arm'S Tech server, sorry for not remembering
it by heart
but I'm not using my machine right now, sorry.
That is what you need, tested on all Acorn machines :)
Cheers,
GUS
Andrew Wingate
"rg" <gus...@otenet.gr> wrote:
> Wacky-Talky supports claiming *any* RO SWI with the best way, without
> slowing down the rest of the SWIs. Using WT_ClaimSWI & WT_ReleaseSWI,
> any SWI can be used as a vector.
>
> You ca find WT (Wacky-Talky) at Arm'S Tech server, sorry for not
> remembering it by heart but I'm not using my machine right now, sorry.
http://www-vis.imag.fr/ArmsTech/GUS/ is where you can find it.
--
Andy Wingate <xy...@null.net>
http://www.ox.compsoc.net/~xyzzy
The avalanche has already started
- it is too late for the pebbles to vote