confused about ARM
Error0x4c
Reading web pages like the "ARM Assembly Programming on the HP49G+" i
understood that its possible to run ARM code "embedding" it in saturm
asm code as described in that page. Thats necessary because hp49g+
emulates a saturn and then expects a program to be saturn instructions.
But reading other document posted here i see there is an ARM mode in
the MASD. So what kind of code is generated by this ARM mode MASD, i
mean, does it need the same trick to run :-/ ?
please be patient as im not a computer scientist and im just trying to
understand.
thanks.
Arnaud
However the system is not designed to cope directly with native ARM
code, it always emulate saturn code.
To run native ARM code you need to locate it at a byte aligned address
and then use a special saturn instruction to jump there and treat the
code as ARM.
So if you generate some native ARM code, you will have to either embed
it in a SATURN code that will do the job described above or use an ARM
launcher to do it for you.
Arnaud
Al Borowski
> Hello,
>
> Reading web pages like the "ARM Assembly Programming on the HP49G+" i
> understood that its possible to run ARM code "embedding" it in saturm
> asm code as described in that page. Thats necessary because hp49g+
> emulates a saturn and then expects a program to be saturn instructions.
> But reading other document posted here i see there is an ARM mode in
> the MASD. So what kind of code is generated by this ARM mode MASD, i
> mean, does it need the same trick to run :-/ ?
Yes. It's not exactly trivial to get ARM code running. You have to make
sure its word-aligned (eg the address of each instruction is a multiple
of 4). Then you move the address of the ARM code into the C register,
and run ARMSAT.
The example code included with the MASD docs does the word-alignment in
a slightly different way. It copies the ARM code to 0x80100. This
location is unused, word-aligned, and is 250 bytes long. So you can't
use it for any non-trivial programs.
I don't see much point in programming assembler. It takes too long to
do. The only real advantage is small size - but there is quite a lot of
storage for programs anyway. You can also use MASD directly on the
calculator, if you enjoy entering data on a tiny screen/keyboard :)
Al
werty
order to get to generic
suedo code and then write it in Forth ARM ?
1) get a very basic Forth running under ARM / 49G+
2) write the Saturn stuff into Forth .
Claudio Lapilli
Hello,
Just a small addition, since I know many people may be interested in
the following code snippets, both for the new MASD:
1) The following code is a minimalist launcher, similar to the one
found in the docs, but without the limitation in the size of the
program (which Al correctly pointed out) when using 80100. Of course,
you need enough free ram (not checked here) to contain a copy of the
ARM program + 128 bytes.
CODE
% SMALL ARM LAUNCHER
SAVE
GOSUB SKIPCODE
% INSERT ARM CODE HERE
!ARM
% TEST CODE - RETURN ONLY
MOV PC,LR
!ASM
*SKIPCODE
A=PC
A=A-4.A
C=RSTK
ACEX.A
D0=C % END OF BLOCK
C=C-A.A % NIBBLES TO COPY
D1=(2) 0 % ALIGN
MOVEUP
CD1EX
ARMSAT
LOADRPL
ENDCODE
@
2) The following is a generic template based on that doc which
generates a string to be executed by the ARMToolBox launcher.
!ASM
!NO CODE
CP=0
DCCP #1028 SAT_READ
DCCP #1028 SAT_WRITE
DCCP #260 SAT_PRIOR
DCCP 4 S_AL
DCCP 4 S_AH
DCCP 4 S_BL
DCCP 4 S_BH
DCCP 4 S_CL
DCCP 4 S_CH
DCCP 4 S_DL
DCCP 4 S_DH
DCCP 4 S_R0L
DCCP 4 S_R0H
DCCP 4 S_R1L
DCCP 4 S_R1H
DCCP 4 S_R2L
DCCP 4 S_R2H
DCCP 4 S_R3L
DCCP 4 S_R3H
DCCP 4 S_R4L
DCCP 4 S_R4H
DCCP 4 S_D0
DCCP 4 S_D1
DCCP 4 S_P
DCCP 4 S_P4
DCCP 4 S_P432
DCCP 4 S_ST
DCCP 4 S_CARRY
DCCP 4 S_HEXDEC
DCCP #32 S_RSTK
DCCP 4 S_RSTKPTR
STRING
{
¢L³€ARM!¢ % THIS IS "L", "³" (CHAR 179), THE ANGLE (CHAR
128), "ARM!"
!ARM
*ARMSTART
% ARM CODE OR DATA HERE
*MAIN
% ARM ENTRY POINT
% MORE CODE OR DATA
$(8) 0 % NO SECONDARY E.P.
$(8) 0 % NO RAM REQUIRED
$(8) MAIN-ARMSTART % ENTRY PT
$(8) 0 % BASE ADDRESS
¢L3v1¢ % TABLE ID , ASCII STRING "L3v1" (CASE IS IMPORTANT!)
!ASM
}
@
I hope this is useful to somebody,
Claudio
Jean-Yves Avenard
> Hello,
> CODE
>
> % SMALL ARM LAUNCHER
> SAVE
>
> GOSUB SKIPCODE
> % INSERT ARM CODE HERE
> !ARM
> % TEST CODE - RETURN ONLY
> MOV PC,LR
> !ASM
> *SKIPCODE
> @
>
This is the best receipe to a pretty nasty crash and memory loss.
Ever wondered what would happen to the 128 bytes located *after* your
program's end?
Either you allocate memory and then do your manipulation or you make
your program 128 bytes bigger than what it should (in which case it will
only work once anyway being self modifying and is therefore a really bad
idea).
Jean-Yves
Claudio Lapilli
Jean-Yves Avenard wrote:
<...>
> This is the best receipe to a pretty nasty crash and memory loss.
> Ever wondered what would happen to the 128 bytes located *after* your
> program's end?
>
> Either you allocate memory and then do your manipulation or you make
> your program 128 bytes bigger than what it should (in which case it will
> only work once anyway being self modifying and is therefore a really bad
> idea).
>
> Jean-Yves
Basically, the launcher copies the ARM code below the calculator stack.
The 128 bytes I mentioned is simply because I word-align the program by
using
D1(2)=0, which will "waste" up to 128 bytes.
Let's see with more detail...
GOSUB SKIPCODE
...
*SKIPCODE
A=PC
A=A-4.A (get the address of the *skipcode label = end of ARM
code)
C=RSTK (get the address of the start of the ARM code)
ACEX.A
D0=C % END OF BLOCK (D0=end of ARM CODE)
C=C-A.A % NIBBLES TO COPY (=end-start)
D1=(2) 0 % ALIGN (D1 IS POINTING TO THE CALCULATOR STACK,
ROUND DOWN TO WORD-ALIGN)
(SO FAR, HERE I HAVE D0=END OF SOUCE, D1=END OF DESTINATION, C=NUMBER
OF NIBBLES, SO EVERYTHING LOOKS GOOD)
MOVEUP
(NOW HERE D1=START OF ARM CODE AT DESTINATION ADDRESS, LAST ADDRESS
USED BY THE ARM PROGRAM IS IN AVERAGE 128 BYTES BELOW THE STACK)
CD1EX (C=START OF ARM CODE)
ARMSAT
I still can't see anything wrong with my code, and I used it several
times.
I think you misinterpreted what the code does, or I have a big mistake
I'm not aware of. If you see something wrong, please point me where the
problem is and I'll fix it.
Regards,
Claudio
Cyrille de Brébisson
you might want to add a $80BEE (cash flush) before the ARMSAT, it might help
sometimes...
regards, cyrille
"Claudio Lapilli" <pleased...@isp.com> wrote in message
news:1121465867.5...@g44g2000cwa.googlegroups.com...
CODE
!ASM
!NO CODE
STRING
{
˘Lł?ARM!˘ % THIS IS "L", "ł" (CHAR 179), THE ANGLE (CHAR
Claudio Lapilli
I advice everybody using my code to revise it as follows:
...
MOVEUP
CD1EX
$80BEE
ARMSAT
LOADRPL
...
But... this is for 49G+ only. Remove the $80BEE for use in HP48GII or
HP39G+.
Claudio
Jean-Yves Avenard
> But... this is for 49G+ only. Remove the $80BEE for use in HP48GII or
> HP39G+.
On the other hand, for the other ARM based calculator it should do
nothing in theory
JY
Claudio Lapilli
Hi,
I see, that's excellent! I assumed that an invalid opcode would crash.
I'll use it for all calcs then.
Thanks,
Claudio
Arnaud Amiel
>
I haven't had time to look at it yet but what is the $80BEE doing?
Arnaud
Claudio Lapilli
It flushes the ARM processor caches. It avoids problems related to the
particular behavior of the ARM cache, which cause applications to act
erratically sometimes, with possible unexpected, hard-to-explain
crashes.
Claudio
Cyrille de Brébisson
typically, to run ARM code, you do as follow:
copy the ARM code at a known 4byte allign address
jump to the ARM code...
now, if you dig in more details, copying the ARM code is a memory write
operation
to execute the ARM code, the ARM cpu needs to read memory for execution
if you dig even deeper, you will see that the ARM has cache memory, I do not
know if you are familiar with cache or not, so here is a breif explanation:
Cache memory is a "trick" used to speed up memory access by having a copy of
memory data in a small memory area which is located close to the CPU. think
about it as a pantry in which you have a small amount of often used products
(salt, shugal, flour...) so you do not need to go to the store every time
you need one of them.... or like a trash can, so you can drop stuff easely
without have to go all the way to the recycle bin outside your house...
well, the ARM has 2 such caches, one is for memory access, one if for
instruction (ie: if you do a memory wread or write, the Data cache (DCache)
is used, if you execute code, the Instruction cache is used)....
the ARM Dcache works as follow: when you write data in memory, if the data
was already in the cache, the data in the cache gets updated, else, the
memory itsenf is updated. When you read data from memory, if the data was in
the cache, you get the data from there, if the data was not in the cache, a
space in the cache is "cleaned" up by copying the data back in the main
memory, and then the new data is loaded in the cache and to the CPU....
("old" data is choosen to be cleaned)...
now, the problem should be more visible, when you write your ARM code in
memory, only the DCache is modified, not the actuall memory, then when you
try to execute the ARM code, the ICache will be loaded FROM MAIN MEMORY,
where, chances are, the data that you just wrote was not yet copied (because
the cache did not need to be cleaned yet), causing you to execute something
different than what you thought you were executing!
the $80BEE instruciton causes the ARM to clean all of the D-Cache and to
invalidate the I-Cache in order to be sure that the memory is up to date....
hope that this helps...
"Arnaud Amiel" <aam...@hotmail.com> wrote in message
news:BuxDe.4949$Oe4...@newsfe3-gui.ntli.net...
Arnaud Amiel
"Cyrille de Brébisson" <cyr...@hp.com> wrote in message
news:kVNDe.8977$fM....@news.cpqcorp.net...
Thanks, very clear indeed. Maybe I should read a bit more the ARM spec (I
just read the assembly coding part where it was not obvious there was a
cache)
Arnaud
Claudio Lapilli
Just to complete the thread, and to help other people to avoid
struggling with cache bugs, here is a "demo" (a piece of code is worth
more than a thousand words) of what kind of effects (besides headaches)
you can expect from cache problems:
(you need to have the development library attached)
<< #08041110h "1234567890" POKEARM
#08041110h #5h PEEKARM >>
store it for further tests:
'TESTPROG' STO
The program above pokes 1234567890 to an ARM address, and then reads
the same address to see what number was stored there. It should
(obviously) return "1234567890" to the stack.
If you run it once you see the right result.
Now run it repeatedly:
<< 0. 100. FOR I TESTPROG NEXT >>
(or execute TESTPROG directly from the keyboard several times)
Look at the results on the stack (scroll up) to find that not all the
results are "1234567890". There's nothing wrong with the UserRPL
program, also both POKEARM and PEEKARM are correct, bug-free, etc. and
still they fail from time to time.
If you add:
CODE
$80BEE
RPL
ENDCODE
before POKEARM and PEEKARM in the example, the bug goes away.
The problem is exactly as Cyrille described, and things like this can
happen with the small launcher I posted earlier if you don't add the
$80BEE.
This is a kind of bug that can give you nightmares, so it's better to
avoid.
Claudio
Error0x4c
too?
thanks.
Claudio Lapilli
Yes, but only in some cases (the fix is coming with the next release
anyway).
If (and only if):
1) you use it to launch your own ARM assembler programs (I mean
non-hpgcc)
and
2) you are using the program as a string in the stack (program is not
stored in a variable or in a port)
and
3) you try to run 2 different programs one immediately after another
then you may encounter something like this. What I experienced (with
early versions of the Toolbox) was that sometimes programs returned
immediately without (apparently) being executed. It only happens with
small programs executed rapidly in sequence. Large programs don't have
problems because the processor cache is very small, and the problem
occurs when there is a cache hit between two different programs.
The problem cannot happen with hpgcc programs, because they flush the
caches at startup.
Claudio