Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #6507 > unrolled thread

File type of machine code? Where does it start?

Back to article view | Back to comp.sys.acorn.programmer

Contents

  File type of machine code? Where does it start? Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-07 17:41 +0200
    Re: File type of machine code? Where does it start? Martin <News03@avisoft.f9.co.uk> - 2025-06-07 18:14 +0100
      Re: File type of machine code? Where does it start? Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-08 18:26 +0200
    Re: File type of machine code? Where does it start? Theo <theom+news@chiark.greenend.org.uk> - 2025-06-08 11:02 +0100
      Re: File type of machine code? Where does it start? Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-08 18:32 +0200
        Re: File type of machine code? Where does it start? Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-19 07:22 +0200
          Re: File type of machine code? Where does it start? Jean-Michel <jmc.bruck@orange.fr> - 2025-06-19 11:23 +0200
            Re: File type of machine code? Where does it start? druck <news@druck.org.uk> - 2025-06-24 20:47 +0100
              Re: File type of machine code? Where does it start? Bob Latham <bob@sick-of-spam.invalid> - 2025-06-25 09:29 +0100
          Re: File type of machine code? Where does it start? Martin <News03@avisoft.f9.co.uk> - 2025-06-19 10:48 +0100
            Re: File type of machine code? Where does it start? Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-20 17:22 +0200
              Re: File type of machine code? Where does it start? Matthew Phillips <spam2011m@yahoo.co.uk> - 2025-06-21 08:20 +0100
          Re: File type of machine code? Where does it start? Theo <theom+news@chiark.greenend.org.uk> - 2025-06-20 17:25 +0100

#6507 — File type of machine code? Where does it start?

What is the file type of machine code? In Bruce Smith book "Raspberry Pi
Assembly Language" he saves a block of memory with the command *save
<filename> <startaddr>+<length>. The saved file has no file type. By a
double click the code is running from the desktop in single mode, though.

Where do I find the starting point of such a code? What is the address
where the machine code is starting?

On the Commodore 64 (or Mega65) you will type

SYS <address> to start machine code at address.

When I examine an absolute file in StrongEd (dump mode), the first line
always at address 8000. Is this also the starting point of the code?

Thanks in advance,

Alex

-- 
http://home.chiemgau-net.de/ausserstorfer/

[toc] | [next] | [standalone]

#6509

In article <5c294dfd2cbavariasound@chiemgau-net.de>,
   Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
> What is the file type of machine code? In Bruce Smith book
> "Raspberry Pi Assembly Language" he saves a block of memory with
> the command *save <filename> <startaddr>+<length>. The saved file
> has no file type. By a double click the code is running from the
> desktop in single mode, though.

Saved like that it will have no filetype (and no date) - instead it
has a load and exec address, which default to <startaddr>

Use *Help Start for more details.
Display the file in the Filer with full info and it will show the load
& start addresses.

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#6511

In article <5c29568075News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <5c294dfd2cbavariasound@chiemgau-net.de>,
>    Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
>> What is the file type of machine code? In Bruce Smith book
>> "Raspberry Pi Assembly Language" he saves a block of memory with
>> the command *save <filename> <startaddr>+<length>. The saved file
>> has no file type. By a double click the code is running from the
>> desktop in single mode, though.

> Saved like that it will have no filetype (and no date) - instead it
> has a load and exec address, which default to <startaddr>

Thanks! I found something on page 2-15 of RISC OS 3 Programmer's
Reference Manual Volume 2.

| Load and execution addresses
|
| In the case of a simple machine code program these are the load and
| exection addresses of the program:

[...]

> Use *Help Start for more details.
> Display the file in the Filer with full info and it will show the load
> & start addresses.

Many thanks! This I was missing, and you answered my question before I
asked.

A.

-- 
http://home.chiemgau-net.de/ausserstorfer/

[toc] | [prev] | [next] | [standalone]

#6510

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
> What is the file type of machine code? In Bruce Smith book "Raspberry Pi
> Assembly Language" he saves a block of memory with the command *save
> <filename> <startaddr>+<length>. The saved file has no file type. By a
> double click the code is running from the desktop in single mode, though.
> 
> Where do I find the starting point of such a code? What is the address
> where the machine code is starting?

This is the territory of executable formats.

When you assemble some code in BASIC, it's assembled to a particular address
which is whereever it happened to be stored in your program.  eg:

DIM buf% 100
P%=buf
[MOV R0, #42: MOV PC, R14
PRINT USR buf%

will assemble the code to run at whatever address buf% happened to be allocated
when you ran the program, which depends on the other things in memory (like
the length of your program)

If instead of the DIM you wrote:
buf% = &A000

then the code would be assembled to start at a fixed address of &A000.  (But
you wouldn't do this because if you made the program longer you'd end up
assembling the code over the top of it and corrupting it)

If you *Save mycode A000+8

it'll produce an untyped file with load/exec address &A000.  If you run
this, the OS will make a new application slot, load the code to address
&A000 and run it.  The code is unable to be run at any address except &A000. 
Exec addresses are mostly a hangover from the BBC Micro and it's strongly
recommended not to use them.

Generally you don't want to write code that way because you need it to run
in a certain environment.  Outside of running things from inside BASIC there
are three main environments in which code runs:

'Application' - Absolute &FF8 filetype - expected to have an Acorn Image
File (AIF) header.  Runs at &8000 in its own application slot.  Code need
not be position-independent code (PIC) because it knows it's loaded at
&8000.  When you run an Absolute from the desktop the OS will create a fresh
Wimpslot for it so it can run at &8000 as it expects.  If you run an
Absolute from within another application (eg BASIC) you should expect it to
overwrite the current application - ie you won't be able to return to your
BASIC program again because it's been overwritten.

'Relocatable Module' - Module &FFA - with module header with various entry
points.  OS allocates some space in the relocatable module area (RMA) and
loads it there.  Code must be PIC because we don't know the address
beforehand.  Runs with operating system privilege (supervisor mode rather
than user mode) which allows access to more functionality (eg can answer SWI
calls and add *commands) but easier to crash system.

'Utility' - Utility &FFC - designed for small standalone programs like
providing disc-based *commands.  Runs position-independent in user mode, but
doesn't allocate its own Wimpslot (ie doesn't start a full application or
turf out the application currently running).  Gets its own user stack but
must be able to run PIC as it could be loaded anywhere in memory.


If you're going to be writing programs you want to run by double clicking
or by *command, probably simplest to get started is the Utility.  You don't
have to deal with getting the various headers and entry points right that
you need for your own AIF or module.  If you're going to be writing full
applications (eg multitasking) then you likely need an application slot and
that means AIF.

(or perhaps an Application Module, but that's more advanced)

> On the Commodore 64 (or Mega65) you will type
> 
> SYS <address> to start machine code at address.

From BASIC you can:

CALL <address>  : starts the code at that address, no results returned
Variables A% to H% supply r0-r7 (there's also more advanced ways to pass
parameters)

ret%=USR <address>   : starts the code, returns the value of r0 into ret%
A% etc work as above

For the CLI you can also:

*Run mycode   - execute file 'mycode', assuming it has an executable
filetype (FF8/FFA/FFC) or an execution address

*Go <address>  - start code at a given address.  Note this may wipe out the
current application context, eg if you run it from BASIC it may return to a
* prompt and wipe your BASIC program.

> When I examine an absolute file in StrongEd (dump mode), the first line
> always at address 8000. Is this also the starting point of the code?

Originally this was just a big block of code to start at &8000. 
Often executables were compressed and so the first instruction was a branch
to the decompression code.

Nowadays there's a requirement for an AIF header and if you just make a lump
of code without a header you may find the system complains it's not 32-bit
compatible if it can't find the '32 bit ok' flag in the right place in the
header.  But aside from the modern requirement to have a header it's still
just code expecting to be loaded at &8000 - you just need to provide an
entry point in the header that will be called, rather than directly jumping
to &8000 as in the old days.

Paolo has a good overview here:
https://paolozaino.wordpress.com/2020/08/07/risc-os-introduction-to-the-arm-aif-object-file-format/

(there's a lot more stuff targeted at C programmers, but basically all you
really care about is the EntryPoint and the Address mode flag to say it's 32
bit compatible)

Theo

[toc] | [prev] | [next] | [standalone]

#6512

In article <lKm*MFveA@news.chiark.greenend.org.uk>,
   Theo <theom+news@chiark.greenend.org.uk> wrote:
> Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

>> What is the file type of machine code? In Bruce Smith book "Raspberry Pi
>> Assembly Language" he saves a block of memory with the command *save
>> <filename> <startaddr>+<length>. The saved file has no file type. By a
>> double click the code is running from the desktop in single mode, though.
>>
>> Where do I find the starting point of such a code? What is the address
>> where the machine code is starting?

> This is the territory of executable formats.

[...]

Many thanks! I found the Appendix D: Code file formats in RISC OS 3
Programmer's Reference Manual Volume 4. I'm not sure if I will
understand that all. It's a shame that I never read about that in the
GAG-News or any other publication in a clear understandable way.

A.

-- 
http://home.chiemgau-net.de/ausserstorfer/

[toc] | [prev] | [next] | [standalone]

#6520

In article <5c29d67fbebavariasound@chiemgau-net.de>,
   Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
> In article <lKm*MFveA@news.chiark.greenend.org.uk>,
>    Theo <theom+news@chiark.greenend.org.uk> wrote:
>> Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:


>>> Where do I find the starting point of such a code? What is the address
>>> where the machine code is starting?

> > This is the territory of executable formats.

> [...]

> Many thanks! I found the Appendix D: Code file formats in RISC OS 3
> Programmer's Reference Manual Volume 4. I'm not sure if I will
> understand that all. It's a shame that I never read about that in the
> GAG-News or any other publication in a clear understandable way.

I created a new file in !StrongEd and saved it with file type
"application". You can change the file type while saving the file to
anywhere. Then opened the file again. It may be required to chance the
mode to 'dump'. Clicked on 'byte'. Now you can write the commands like
you wish. The last command should always be E0 F0 A0 E1. Then saved the
file and started it by a double click. You can add the command 00 00 A0
E1 (what is doing nothing of course) before. And so on.

I have no idea, why 'word' and 'byte' are reversed. When you click on
word, you have to write

E1 A0 00 00
E1 A0 F0 E0

of course. This is the format it is descripted in the manual of the ARM
(Arm A32/T32 Instrution Set for A-profile architecture) I have here.

An application will always be loaded and started by RISC OS on address
&08000. This is a bit strange because RISC OS can hold different
applications at the same time in the RAM. Normally, the programs would
be overwritten when all are loaded at the same location of memory. But
between the ARM and the RAM you have the MEMC (this I grab from the PRMs 3
- is that still the case today?). The MEMC maps the memory for the
applications and moves it to elsewhere, to a place where is free
memory.

With the instruction A1 A0 F0 E0 at the end you will give the controll
back to RISC OS. It moves the address which was stored in register &E
before calling the programm, back to register &F, which is the programm
counter of the ARM.

For this part I was looking long. It seems to me that there is no direct
introduction to that issue. But it is so fundamental. And it is very
easy to understand. You can examine an application that way, too!

It may look a bit strange to other people to instruct the computer in
such a - I'll call it - 'hard' way. It is the direct way. It is machine
code. The problem is if you are not learning it this 'hard' way and if
you are using all the helpers (assemblers, compilers) from the beginning
on you won't learn real coding nor create an understanding in this issue.

They created the Raspberry Pi to give the people cheap computers to
learn. This alone won't work, of course. You have to give the people the
information to learn, too. And I think this isn't happen. There is a lot
of publication around but nothing what may help people to understand
what's going on. It would be so helpful to have such an publication.

I'm a bit confused by the huge amount of documentation I found about the
ARM. It seems to me that there are existing much different ARM chips
today. What are the differences? Which ones are relevant for RISC OS
today? I'm have some Raspberry Pi's and an Elesar's Titanium. Never read
about this issue.

I'm also a bit confused about the documentation. I have the Programmer's
Reference Manuals here. But they are for RISC OS 3. What was chanced in
meantime, what is still valid from them today? Never read about that issue.

I'll still work further on this project and will still extending my script
about coding the ARM in machine code (later I may include assembler) under
RISC OS. Unfortunately, I'll o all this in German because it is easier for
me. The script will be free available on my web site. I'll update it from
time to time.

Thank you very much for all your help here.

A.
A.

-- 
http://home.chiemgau-net.de/ausserstorfer/

[toc] | [prev] | [next] | [standalone]

#6522

In message <5c2f4363e6bavariasound@chiemgau-net.de>
          Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

> In article <5c29d67fbebavariasound@chiemgau-net.de>,
>    Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
>> In article <lKm*MFveA@news.chiark.greenend.org.uk>,
>>    Theo <theom+news@chiark.greenend.org.uk> wrote:
>>> Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:


>>>> Where do I find the starting point of such a code? What is the address
>>>> where the machine code is starting?

>>> This is the territory of executable formats.

>> [...]

>> Many thanks! I found the Appendix D: Code file formats in RISC OS 3
>> Programmer's Reference Manual Volume 4. I'm not sure if I will
>> understand that all. It's a shame that I never read about that in the
>> GAG-News or any other publication in a clear understandable way.

> I created a new file in !StrongEd and saved it with file type
> "application". You can change the file type while saving the file to
> anywhere. Then opened the file again. It may be required to chance the
> mode to 'dump'. Clicked on 'byte'. Now you can write the commands like
> you wish. The last command should always be E0 F0 A0 E1. Then saved the
> file and started it by a double click. You can add the command 00 00 A0
> E1 (what is doing nothing of course) before. And so on.

> I have no idea, why 'word' and 'byte' are reversed. When you click on
> word, you have to write

> E1 A0 00 00
> E1 A0 F0 E0

> of course. This is the format it is descripted in the manual of the ARM
> (Arm A32/T32 Instrution Set for A-profile architecture) I have here.

endianess
https://en.wikipedia.org/wiki/Endianness

From DDE.Codestds.AOF
There are two sorts of AOF: <little-endian> and <big-endian>.

In little-endian AOF, the least significant byte of a word or half-word 
has the lowest address of any byte in the (half-)word. This <byte sex> is 
used by DEC,Intel and Acorn, amongst others.

In big-endian AOF, the most significant byte of a (half-)word has the 
lowest.address. This byte sex is used by IBM, Motorola and Apple, amongst 
others.

> Thank you very much for all your help here.

> A.
> A.



-- 
Jean-Michel

[toc] | [prev] | [next] | [standalone]

#6528

On 19/06/2025 10:23, Jean-Michel wrote:
>  From DDE.Codestds.AOF
> There are two sorts of AOF: <little-endian> and <big-endian>.
> 
> In little-endian AOF, the least significant byte of a word or half-word
> has the lowest address of any byte in the (half-)word. This <byte sex> is
> used by DEC,Intel and Acorn, amongst others.
> 
> In big-endian AOF, the most significant byte of a (half-)word has the
> lowest.address. This byte sex is used by IBM, Motorola and Apple, amongst
> others.

Never seen a big endian AOF in the wild, and suspect no-one else has either.

I can only guess it was specified as a result of Sam Wauchope's crazed 
ideas about running a successor to RISC OS on Power PC or something.

---druck

[toc] | [prev] | [next] | [standalone]

#6529

In article <103evcp$27cdp$1@dont-email.me>,
   druck <news@druck.org.uk> wrote:
> On 19/06/2025 10:23, Jean-Michel wrote:
> >  From DDE.Codestds.AOF
> > There are two sorts of AOF: <little-endian> and <big-endian>.
> > 
> > In little-endian AOF, the least significant byte of a word or
> > half-word has the lowest address of any byte in the (half-)word.
> > This <byte sex> is used by DEC,Intel and Acorn, amongst others.
> > 
> > In big-endian AOF, the most significant byte of a (half-)word has
> > the lowest.address. This byte sex is used by IBM, Motorola and
> > Apple, amongst others.

> Never seen a big endian AOF in the wild, and suspect no-one else
> has either.

> I can only guess it was specified as a result of Sam Wauchope's
> crazed ideas about running a successor to RISC OS on Power PC or
> something.


At first sight there is a strangeness to the data inside flac music
files. They appear to use both big and little endian vaules which
they do in a way and they don't at the same time. They often use the
hi-byte for flags and blockid purposes.

Here is the start of a flac file...

0000       fLaC
0004       [00][00][00][22]        (low byte last  Big-endian)
0008       <34 bytes of data for STREAMINFO BLOCK>

002A [04][00][02][B7]  <= 04 says vorbis comment not last block,     
                         length = &02B7 (low byte last)
002E  [20][00][00][00]reference libFLAC 1.2.1 20070917               
                         (low byte first)
0032  [16][00][00][00]     <= number of items in list

But also in the same file..

  [0E][00][00][00]TOTALTRACKS=28
  [0C][00][00][00]TOTALDISCS=2
  [26][00][00][00]TITLE=Third Movement (Cellos & Basses)
  [14][00][00][00]ARTIST=Gustav Mahler
  [2C][00][00][00]ALBUM=Symphony No. 2 "Resurrection" [Kaplan]
  [09][00][00][00]DATE=1988

These are actual values taken from a flac track.

Bob.

[toc] | [prev] | [next] | [standalone]

#6524

I have replied to some of your points...

In article <5c2f4363e6bavariasound@chiemgau-net.de>,
   Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
> I created a new file in !StrongEd and saved it with file type
> "application". 

There is no filetype for 'Application', so not sure what you mean
here. Application is a special name given to a directory (not a file)
that starts with a ! (an exclamation mark, commonly referred to as a
pling in this context)

[Snip]

> An application will always be loaded and started by RISC OS on
> address &08000. This is a bit strange because RISC OS can hold
> different applications at the same time in the RAM. Normally, the
> programs would be overwritten when all are loaded at the same
> location of memory. But between the ARM and the RAM you have the
> MEMC (this I grab from the PRMs 3 - is that still the case today?).
> The MEMC maps the memory for the applications and moves it to
> elsewhere, to a place where is free memory.

Applications do always appear to start at &8000, but this is just a
'virtual' address. It will actually be at a physical real address, and
the translation is done for you by RISC OS so you always deal with the
virtual addresses. There is no longer a MEMC chip involved. 

[Snip]

> It seems to me that there are existing much
> different ARM chips today. What are the differences? Which ones are
> relevant for RISC OS today? I'm have some Raspberry Pi's and an
> Elesar's Titanium. Never read about this issue.

There is lots on the web, but probably best place to start is
https://www.riscosopen.org

Click on Library, go down to Programmer Documentation and click on the
Programmer Documentation link, then click on ARMV6+ compatibility
primer. You should end up at
https://www.riscosopen.org/wiki/documentation/show/ARMv7%20compatibility%20primer
but it gives you an idea of other things available on this one site.

> I'm also a bit confused about the documentation. I have the
> Programmer's Reference Manuals here. But they are for RISC OS 3.
> What was chanced in meantime, what is still valid from them today?

Most of it is still valid with RO5, apart from the 26bit to 32bit
changes. An updated version of the PRMs is being worked on ... but it
is a mammoth project.  If you click on Bounties at the top of the ROOL
page, you will see details of the work for Revide PRMs step 1.

Some updates since RO3 are available in the ROOL Library, and the
Style Guide, BASIC and DDE manuals have all been updated.

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#6526

In article <5c2f5bb58bNews03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> I have replied to some of your points...

> In article <5c2f4363e6bavariasound@chiemgau-net.de>,
>    Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
>> I created a new file in !StrongEd and saved it with file type
>> "application".

> There is no filetype for 'Application', so not sure what you mean
> here. Application is a special name given to a directory (not a file)
> that starts with a ! (an exclamation mark, commonly referred to as a
> pling in this context)

Pardon, I meant the file type "absolute". It is not always so easy to
work here in the "shelter" for the homeless. It is very public here. I
was disturbed very often.

http://home.chiemgau-net.de/ausserstorfer/Temp/2025-06-20/Absolute.jpg (60
kB)

> [Snip]

>> An application will always be loaded and started by RISC OS on
>> address &08000. This is a bit strange because RISC OS can hold
>> different applications at the same time in the RAM. Normally, the
>> programs would be overwritten when all are loaded at the same
>> location of memory. But between the ARM and the RAM you have the
>> MEMC (this I grab from the PRMs 3 - is that still the case today?).
>> The MEMC maps the memory for the applications and moves it to
>> elsewhere, to a place where is free memory.

> Applications do always appear to start at &8000, but this is just a
> 'virtual' address. It will actually be at a physical real address, and
> the translation is done for you by RISC OS so you always deal with the
> virtual addresses. There is no longer a MEMC chip involved.

Thanks. Let do that task RISC OS means doing it by software. Isn't that
a brake for the performance?

It would also be good to know how this works under Android, for example.
I have a Gemini-PDA which runs this OS. And which editor could be used
there.

> [Snip]

>> It seems to me that there are existing much
>> different ARM chips today. What are the differences? Which ones are
>> relevant for RISC OS today? I'm have some Raspberry Pi's and an
>> Elesar's Titanium. Never read about this issue.

> There is lots on the web, but probably best place to start is
> https://www.riscosopen.org

Thanks. Web is very expensive. I cannot be often and long en ligne.
Also, most of the web pages today just won't work anymore. I have to go
to elsewhere to get them correct on the screen. It is very complicated
to work this way. It is better to have the information bundled on the
machine.

The web today is very inefficient when you count the amount of data and
the result (what you need or want to know).

What about the programm counter? Was there any changes to it since the
release of the PRMs for RISC OS 3?

> Click on Library, go down to Programmer Documentation and click on the
> Programmer Documentation link, then click on ARMV6+ compatibility
> primer. You should end up at
> https://www.riscosopen.org/wiki/documentation/show/ARMv7%20compatibility%20primer
> but it gives you an idea of other things available on this one site.

>> I'm also a bit confused about the documentation. I have the
>> Programmer's Reference Manuals here. But they are for RISC OS 3.
>> What was chanced in meantime, what is still valid from them today?

> Most of it is still valid with RO5, apart from the 26bit to 32bit
> changes. An updated version of the PRMs is being worked on ... but it
> is a mammoth project.  If you click on Bounties at the top of the ROOL
> page, you will see details of the work for Revide PRMs step 1.

> Some updates since RO3 are available in the ROOL Library, and the
> Style Guide, BASIC and DDE manuals have all been updated.

Pardon, I don't understand that. Changes should be documented and
published always on the fly. I often read about the issue of 26 bit code
and 32 bit code in the GAG news for example. But there was never an
explanation of that. The articles there are always just on the face of
it.

A.

-- 
http://home.chiemgau-net.de/ausserstorfer/

[toc] | [prev] | [next] | [standalone]

#6527

In message <5c2ffe1635bavariasound@chiemgau-net.de>
 on 20 Jun 2025 Alexander Ausserstorfer  wrote:

>>> An application will always be loaded and started by RISC OS on
>>> address &08000. This is a bit strange because RISC OS can hold
>>> different applications at the same time in the RAM. Normally, the
>>> programs would be overwritten when all are loaded at the same
>>> location of memory. But between the ARM and the RAM you have the
>>> MEMC (this I grab from the PRMs 3 - is that still the case today?).
>>> The MEMC maps the memory for the applications and moves it to
>>> elsewhere, to a place where is free memory.

>> Applications do always appear to start at &8000, but this is just a
>> 'virtual' address. It will actually be at a physical real address, and
>> the translation is done for you by RISC OS so you always deal with the
>> virtual addresses. There is no longer a MEMC chip involved.

> Thanks. Let do that task RISC OS means doing it by software. Isn't that
> a brake for the performance?

The functions of the separate MEMC are now integrated into the processor, 
so it is done in hardware.  RISC OS manages that for you.

> What about the program counter? Was there any changes to it since the
> release of the PRMs for RISC OS 3?

The main change is the 32-bit addressing, so the flags are no longer found 
in the program counter, they are in the CPSR (Current Program Status 
Register) instead.  The MRS and MSR opcodes allow you to copy this to or 
from an ordinary register, but this is rarely needed.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#6525

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
> I created a new file in !StrongEd and saved it with file type
> "application". You can change the file type while saving the file to
> anywhere. Then opened the file again. It may be required to chance the
> mode to 'dump'. Clicked on 'byte'. Now you can write the commands like
> you wish. The last command should always be E0 F0 A0 E1. Then saved the
> file and started it by a double click. You can add the command 00 00 A0
> E1 (what is doing nothing of course) before. And so on.
> 
> I have no idea, why 'word' and 'byte' are reversed. When you click on
> word, you have to write

RISC OS uses the Arm chip in 'little endian' mode, where the least
significant byte of a word comes first.  Others have given the wikipedia
link.

> E1 A0 00 00
> E1 A0 F0 E0
> 
> of course. This is the format it is descripted in the manual of the ARM
> (Arm A32/T32 Instrution Set for A-profile architecture) I have here.
> 
> An application will always be loaded and started by RISC OS on address
> &08000. This is a bit strange because RISC OS can hold different
> applications at the same time in the RAM. Normally, the programs would
> be overwritten when all are loaded at the same location of memory. But
> between the ARM and the RAM you have the MEMC (this I grab from the PRMs 3
> - is that still the case today?). The MEMC maps the memory for the
> applications and moves it to elsewhere, to a place where is free
> memory.

MEMC was the original chip used by RISC OS, but more generally this is the
role of the 'memory management unit' (MMU) which translates virtual
addresses to physical addresses.  Nowadays an MMU is integrated into each
processor core.  Each application appears to start at a 'virtual' &8000
which is translated to some different physical address where the memory
actually stores it.  By changing the base of the current mapping table
('page table'), we can swap one application for another.  This is called
'context switching'.

> With the instruction A1 A0 F0 E0 at the end you will give the controll
> back to RISC OS. It moves the address which was stored in register &E
> before calling the programm, back to register &F, which is the programm
> counter of the ARM.

Yes, normally written in assembler as 'MOV pc, lr' - move link register to
program counter.  The LR holds the location where we were previously, the PC is
where we are now.  Setting the PC to the LR means we now jump back to where
we used to be.

> For this part I was looking long. It seems to me that there is no direct
> introduction to that issue. But it is so fundamental. And it is very
> easy to understand. You can examine an application that way, too!
> 
> It may look a bit strange to other people to instruct the computer in
> such a - I'll call it - 'hard' way. It is the direct way. It is machine
> code. The problem is if you are not learning it this 'hard' way and if
> you are using all the helpers (assemblers, compilers) from the beginning
> on you won't learn real coding nor create an understanding in this issue.

It is helpful to understand the fundamentals, I agree.

> They created the Raspberry Pi to give the people cheap computers to
> learn. This alone won't work, of course. You have to give the people the
> information to learn, too. And I think this isn't happen. There is a lot
> of publication around but nothing what may help people to understand
> what's going on. It would be so helpful to have such an publication.

There's Bruce Smith's book "Raspberry Pi Assembly Language RISC OS
Beginners":
https://www.amazon.co.uk/Raspberry-Assembly-Language-Beginners-Hands/dp/0992391628
previous version:
https://www.amazon.co.uk/Raspberry-Pi-Assembly-Language-Beginners/dp/148112790X

I haven't read this one, but I proof read his OS book.  It was ok but a bit
sloppy in places - I can't comment on this book.

There are a number of other resources available, just not for RISC OS.  eg
Alex Chadwick did a from-scratch tutorial for learning assembler on the
original Raspberry Pi:

https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/

While that applies to the Pi 1 and Pi Zero hardware (but not newer hardware
like the 3 or Zero 2), it's running the assembler on Linux not RISC OS.  So
some adaptation may be needed to run the tutorials, but you can still read
them either way.

> I'm a bit confused by the huge amount of documentation I found about the
> ARM. It seems to me that there are existing much different ARM chips
> today. What are the differences? Which ones are relevant for RISC OS
> today? I'm have some Raspberry Pi's and an Elesar's Titanium. Never read
> about this issue.

Avoid anything talking about 'Thumb' (T32) or 'aarch64'/'Arm64'/A64 as those
are different instruction sets.  The original ARM is now called A32 or
possibly ARMv7 (or earlier numbers).  ARMv8 usually means 64 bit, although
it doesn't always.

There are some differences between different ARM CPUs, from ARM2 to the
current Cortex A-series.  For a beginner under RISC OS they don't really
matter.  The only thing that's really important is the difference between
26-bit and 32-bit addressing.

> I'm also a bit confused about the documentation. I have the Programmer's
> Reference Manuals here. But they are for RISC OS 3. What was chanced in
> meantime, what is still valid from them today? Never read about that issue.

Others have answered the current state.  90% of the old PRM is still
applicable, it's just annoying if you don't know what's been updated.  The
riscosopen.org wiki is quite useful there.  I'd read the PRM for
understanding the big picture (which mostly hasn't changed), and then
consult the wiki to check if the details have changed.

Theo

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web