Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!warwick!csuwr
From: csuwr@warwick.ac.uk (Derek Hunter)
Newsgroups: comp.sys.acorn
Subject: Re: 32bit immediate load in ARM code
Message-ID: <8+R_FJ|@warwick.ac.uk>
Date: 17 May 91 21:27:09 GMT
References: <+|Q_L||@warwick.ac.uk>
Sender: csuwr@cu.warwick.ac.uk
Organization: Computing Services, Warwick University, UK
Lines: 25
Nntp-Posting-Host: lily

In article <+|Q_L||@warwick.ac.uk> csuwr@warwick.ac.uk (I) write . . .

. . . about these 32 bit loads.

 I'm afraid I got it a bit wrong, the DCD for the extended loads should
  add four to P% before anything is done to it.

ie		DCD  VERY_FAR_AWAY-(P%+4)
or		DCD  (P%+4)-VERY_FAR_AWAY

In case the NV code has less precedance than an illegal instruction code,
 (sorry, I haven't tested it yet), you can set the top byte to 0xFF which
 I think takes it into the SWI range of instructions, where there should
 be no possibility of illegal instructions existing, merely lots of never
 executed undefined SWIs. (Not the same thing at all, really).

 Of course you then have to make the obvious modification to the Bic in
 that case, correcting the top byte rather than just the top nybble, but
 for current memory levels, the extended offset addressing shouldn't foul
 up. By the time it does, we'll be into RISC OS 27. (Any rumours available
 about /that/ one Acorn? :-)

	- I was typing from memory, sorry I got it wrong folks.

	- Derek Hunter		csuwr@cu.warwick.ac.uk