🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.acorn.tech
3 messages
3 total messages Started by Brian May#2 Thu, 03 Sep 1992 14:36
ARM3 instructions.
#213
Author: Brian May#2
Date: Thu, 03 Sep 1992 14:36
53 lines
3117 bytes
  I don't have an Archie myself but have used them quite a lot in the past.
I was recently mucking about with a friend's A5000, trying to find the new
instructions that turned the cache on and off. I found them, they were
co-processor instructions with the processor itself as (I think) number 0.

  Anyway, as I was disassembling away I found a new instruction (well, I had
never come across it before). It was 'SWP' and I imagine it swaps registers
with registers, maybe with memory as well? I can't remember. If it does
reg<->mem as well, and is uninterruptable, perhaps it is for use as a
semaphore in multi-processor systems?

  I worked out how it fitted into the instruction set, it is where an
illegal instruction was previously. I think it might have been due to only
four bits for a register shift, five bits for an immediate - hence an extra
bit which would have to be 0 for a normal instruction. I can't really
explain this very coherently but someone will know what I mean!

  I then wrote a program to generate all possible versions of this
instruction, but I didn't print them out... Anyway, it didn't help me work
out what they actually did (if I had my own A5000 I would spend some more
time on it, but I haven't and I'm just interested)

  Of course I won't be the first person to notice this so I wondered, could
someone post some info on this, and also on the co-processor instructions
relevant to the CPU itself?

  Another thing - RiscOs (being quite well designed as it is) has certain
ways of doing things which leads me to ask the question: When I do ...
  *memoryi 03800000 (Is it *memoryi? Is 03800000 ROM? Do I need my own
Archie?)

  ... and a coprocessor instruction is found, which module decodes it? Now
if I wrote Risc-Os, I would get the ARM3 support module to decode the
instructions, and I would get a floating point emulator to decode the FPU
instructions. That way, it's nicely modular and extensible.

  Now, I didn't write Risc-Os, and as I remember, the FPU decoding is done
in the debugger. I looked through the ARM3 support module and found some
text relating to the cache instructions, but not all of them. I couldn't
find any in the debugger.

  If I sound a little vague, please understand that I didn't have all day
to sort this out, and it was two months ago!

Andrew.

ps. Nothing to do with my post, but just to pour petrol on the flames, I'm
gonna buy a 486 PC cos I can get more power for less money, and the screen
doesn't blank when I access the disk drive :-) So if Acorn are listening
(and I think they are!) I think you have a well-defined problem on your
hands. I wonder if someone could write RiscOs for a PC? Or an Archimedes
emulator, now that would be amusing...
Re: ARM3 instructions.
#214
Author: David Seal
Date: Fri, 04 Sep 1992 15:01
150 lines
8105 bytes
In article <4422@gos.ukc.ac.uk> amsh1@ukc.ac.uk (Brian May#2) writes:

>  I don't have an Archie myself but have used them quite a lot in the past.
>I was recently mucking about with a friend's A5000, trying to find the new
>instructions that turned the cache on and off. I found them, they were
>co-processor instructions with the processor itself as (I think) number 0.

Coprocessor 15, in fact.

>  Anyway, as I was disassembling away I found a new instruction (well, I had
>never come across it before). It was 'SWP' and I imagine it swaps registers
>with registers, maybe with memory as well? I can't remember. If it does
>reg<->mem as well, and is uninterruptable, perhaps it is for use as a
>semaphore in multi-processor systems?

The SWP instruction was new to the ARM2as macrocell. I believe ARM3 was the
first full chip which contained it. More recent macrocells and chips like
ARM6, ARM60, ARM600 and ARM610 also contain it.

It only swaps a register with a memory location (either a byte or a word),
and not two registers. It can however read the new contents of the memory
location from one register, and write the old contents of the memory
location to another register - i.e. it doesn't have to do a pure swap. This
may be the source of your idea that it can swap two registers. It is indeed
uninterruptable, and yes, it is intended for semaphores.

>  Of course I won't be the first person to notice this so I wondered, could
>someone post some info on this, and also on the co-processor instructions
>relevant to the CPU itself?

The SWP instruction:
  Bits 31..28: Usual condition field
  Bits 27..23: 00010
  Bit 22:      0 for a word swap, 1 for a byte swap
  Bits 21..20: 00
  Bits 19..16: Base register (addresses the memory location involved)
  Bits 15..12: Destination register (where the old memory contents go)
  Bits 11..4:  00001001
  Bits 3..0:   Source register (where the new memory contents come from)

  Byte swaps use the bottom byte of the source and destination registers,
  and clear the top three bytes of the destination register. There are
  various rules about how R15 works in each register position, similar to
  those for LDR and STR instructions. The destination and source registers
  are allowed to be the same for a pure swap. I don't know offhand what
  would happen if the base register were equal to one or both of the others,
  but I don't think I'd recommend doing it!

  Assembler syntax is (using <> around optional sections):
    SWP<cond><B> Rdest,Rsrc,[Rbase]

The ARM3 cache control registers are all coprocessor 15 registers, accessed
by MRC and MCR instructions in non-user modes. (They will produce invalid
operation traps in user mode.)

Coprocessor 15 register 0 is read only and identifies the chip - e.g.:
  Bits 31..24: &41 - designer code for ARM Ltd.
  Bits 23..16: &56 - manufacturer code for VLSI Technology Inc.
  Bits 15..8:  &03 - identifies chip as an ARM3.
  Bits 7..0:   &00 - revision of chip.

Coprocessor 15 register 1 is simply a write-sensitive location - writing any
value to it flushes the cache.

Coprocessor 15 register 2: a miscellaneous control register.
  Bit 0 turns the cache on (if 1) or off (if 0).
  Bit 1 determines whether user mode and non-user modes use the same address
    mapping. Bit 1 is 1 if they do, 0 if they have separate address
    mappings. It should be 1 for use with MEMC.
  Bit 2 is 0 for normal operation, 1 for a special "monitor mode" in which
    the processor is always run at memory speed and all addresses and data
    are put on the external pins, even if the memory request was satisfied
    by the cache. This allows external hardware like a logic analyser to
    trace the program properly.
  Other bits are reserved for future expansion. Code which is trying to set
    the whole control register (e.g. at system initialisation time) should
    write these bits as zeros to ensure compatibility with any such future
    expansions. Code which is just trying to change one or two bits (e.g.
    turn the cache on or off) should read this register, modify the bits
    concerned and write it back: this ensures that it won't have unexpected
    side effects in the future like turning as-yet-undefined features off.
  This register is reset to all zeros when the ARM3 is reset.

Coprocessor 15 register 3: controls whether areas of memory are cacheable,
    in 2 megabyte chunks. All accesses to an uncacheable area of memory go
    to the real memory and not to the cache - this is a suitable setting
    e.g. for areas containing memory-mapped IO, or for doubly mapped areas
    of memory.
  Bit 0 is 1 if virtual addresses &0000000-&01FFFFF are cacheable, 0 if they
    are not.
  Bit 1 is 1 if virtual addresses &0200000-&03FFFFF are cacheable, 0 if they
    are not.
  :
  :
  Bit 31 is 1 if virtual addresses &3E00000-&3FFFFFF are cacheable, 0 if
    they are not.

Coprocessor 15 register 4: controls whether areas of memory are updateable,
    in 2 megabyte chunks. All write accesses to a non-updateable area of
    memory go to the real memory only, not to the cache - this is a suitable
    setting for areas of memory that contain ROMs, for instance, since you
    don't want the cached values to be altered by an attempt to write to the
    ROM. (Or, as in MEMC, by an attempt to write to write-only locations
    that share an address with the read-only ROMs.)
  Bit 0 is 1 if virtual addresses &0000000-&01FFFFF are updateable, 0 if
    they are not.
  Bit 1 is 1 if virtual addresses &0200000-&03FFFFF are updateable, 0 if
    they are not.
  :
  :
  Bit 31 is 1 if virtual addresses &3E00000-&3FFFFFF are updateable, 0 if
    they are not.

Coprocessor 15 register 5: controls whether areas of memory are disruptive,
    in 2 megabyte chunks. Any write access to a disruptive area of memory
    will cause the cache to be flushed. This is a suitable setting for areas
    of memory which if written, could cause cache contents to become invalid
    in some way. E.g. on MEMC, writing to the physically addressed memory at
    addresses &2000000-&2FFFFFF will also usually change a virtually
    addressed location's contents: if this location is in cache, a
    subsequent attempt to read it would read the old value. To avoid this
    problem, the physically addressed memory should be marked as disruptive
    in a MEMC system. Similarly, any remapping of memory on a MEMC or other
    memory controller should act disruptively, since the cache contents are
    liable to have become invalid.
  Bit 0 is 1 if virtual addresses &0000000-&01FFFFF are disruptive, 0 if
    they are not.
  Bit 1 is 1 if virtual addresses &0200000-&03FFFFF are disruptive, 0 if
    they are not.
  :
  :
  Bit 31 is 1 if virtual addresses &3E00000-&3FFFFFF are disruptive, 0 if
    they are not.

Coprocessor 15 registers 3-5 are in an undefined state after power-up: they
must be programmed correctly before the cache is turned on.

Note that you should check the identity code in coprocessor 15 register 0
identifies the chip as an ARM3 before assuming that the other registers can
be used as stated above, unless you are absolutely certain your code can
only ever be run on an ARM3. Otherwise you are likely to run into problems
with other chips - e.g. an ARM600 uses the same coprocessor 15 registers to
control its cache and MMU, but in a completely different way. Just about the
only thing they do have in common is that coprocessor 15 register 0 contains
an identification code as described above.

David Seal
dseal@armltd.co.uk

All opinions are mine only...
Re: ARM3 instructions.
#215
Author: Axello de Roestello
Date: Fri, 04 Sep 1992 17:26
17 lines
1121 bytes
amsh1@ukc.ac.uk (Brian May#2) writes:
>hands. I wonder if someone could write RiscOs for a PC? Or an Archimedes
>emulator, now that would be amusing...

A colleague of a friend of mine (...) has written an ARM emulator in C and has
ported BBC-Basic V to an IBM RS/6000 workstation. Now he finally has a decent
programming language on his mini computer :-)
(He is quite stiffy so he won't give me the source, maybe I should steal it 
someday...)

Axel

-- 
axel@phys.uva.nl     | In the beginning the Universe was created.
aroest@fwi.uva.nl    | This has made a lot of people very angry
                     | and been widely regarded as a bad move.
                     | (Douglas Adams)
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads