f



Cipher module and MD5

I have been trying to use the Cipher module v0.07 (see
http://www.queen.clara.net/pgp/acorn.html) to create MD5 digests from
simple text strings, all within a program. The Basic code I have used is
just...

    S$ = "abcdefghijk"
    wlen% = 128
    DIM ws% wlen%
    SYS "Cipher_MD5_Start" ,ws%
    SYS "Cipher_MD5_Update",ws%,S$,LEN(S$)
    SYS "Cipher_MD5_End"   ,ws% TO md5%

which looks correct to me, but it Data Aborts in the MD5_End SWI 
    in Module   Cipher              @ &20FDEDF4 + &44C
    in Function module_swi          @ &20FDF1D4 + &6C

which is in the code for MD5_End, doing the STR...
    LDR     R0,[R4,#0]
    ADD     R0,R0,#&58         ; ="X"
->  STR     R0,[R4,#0]

where r4 = &FA207FBC, hence the Data Abort, as it is in User mode.

Things which may (or may not) be relevant include...
1.  Iyonix with RISC OS 5.23 high vectors.
2.  Cipher is a C + assembler module.
3.  The *MD5 command, provided by the module, works ok.
4.  I have doubts that the previous SWIs worked.

Anyone tried anything similar?

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
9/18/2016 4:49:48 PM
comp.sys.acorn.programmer 2499 articles. 0 followers. Post Follow

22 Replies
295 Views

Similar Articles

[PageSpeed] 24

In article <55c19ea163News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> I have been trying to use the Cipher module v0.07 (see
> http://www.queen.clara.net/pgp/acorn.html) to create MD5 digests from
> simple text strings, all within a program. 
>
> Anyone tried anything similar?

There's an md5 command inside !Internet now (for ROOL disc images post dating
September 2014) which will chew a string instead of a file:

*md5 -s "Hello"
MD5 ("Hello") = 8b1a9953c4611296a827abf8c47804d7
*

you could shell out of BASIC, run that, piping the result to a file, then read
the result back in,
Sprow.

0
Sprow
9/19/2016 7:55:41 AM
In message <55c19ea163News03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> I have been trying to use the Cipher module v0.07 (see
> http://www.queen.clara.net/pgp/acorn.html) to create MD5 digests from
> simple text strings, all within a program. The Basic code I have used is
> just...

>     S$ = "abcdefghijk"
>     wlen% = 128
>     DIM ws% wlen%
>     SYS "Cipher_MD5_Start" ,ws%
>     SYS "Cipher_MD5_Update",ws%,S$,LEN(S$)
>     SYS "Cipher_MD5_End"   ,ws% TO md5%

> which looks correct to me, but it Data Aborts in the MD5_End SWI
>     in Module   Cipher              @ &20FDEDF4 + &44C
>     in Function module_swi          @ &20FDF1D4 + &6C

> which is in the code for MD5_End, doing the STR...
>     LDR     R0,[R4,#0]
>     ADD     R0,R0,#&58         ; ="X"
> ->  STR     R0,[R4,#0]

> where r4 = &FA207FBC, hence the Data Abort, as it is in User mode.

How did it get there :-
Just above that instruction - is a BL MD5Final -
so why is R14=&C0?


-- 
Colin Ferris Cornwall UK
0
cferris
9/19/2016 9:39:57 AM
In article <a91cfbc155.cferris@cferris.freeuk.com>,
   <cferris@freeRemoveuk.com.invalid> wrote:
> In message <55c19ea163News03@avisoft.f9.co.uk>
>           Martin <News03@avisoft.f9.co.uk> wrote:

> > I have been trying to use the Cipher module v0.07 (see
> > http://www.queen.clara.net/pgp/acorn.html) to create MD5 digests from
> > simple text strings, all within a program. The Basic code I have used
> > is just...

> >     S$ = "abcdefghijk"
> >     wlen% = 128
> >     DIM ws% wlen%
> >     SYS "Cipher_MD5_Start" ,ws%
> >     SYS "Cipher_MD5_Update",ws%,S$,LEN(S$)
> >     SYS "Cipher_MD5_End"   ,ws% TO md5%

> > which looks correct to me, but it Data Aborts in the MD5_End SWI
> >     in Module   Cipher              @ &20FDEDF4 + &44C
> >     in Function module_swi          @ &20FDF1D4 + &6C

> > which is in the code for MD5_End, doing the STR...
> >     LDR     R0,[R4,#0]
> >     ADD     R0,R0,#&58         ; ="X"
> > ->  STR     R0,[R4,#0]

> > where r4 = &FA207FBC, hence the Data Abort, as it is in User mode.

> How did it get there :-
> Just above that instruction - is a BL MD5Final -
> so why is R14=&C0?

Good question. But I see that the MD5Final routine starts with
    MOV     R12,R13
    STMDB   R13!,{R0,R4,R11,R12,R14,PC}
    SUB     R11,R12,#4
It later uses r14 as a work reg, then and at the end
    LDMDB   R11,{R4,R11,R13,PC}
so r14 does not seem involved in the actual return. 

Weird, perhaps, but it is compiled C!

Presumably you got the same abort as me?

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
9/19/2016 11:15:28 AM
In article <55c1f1910enews@sprow.co.uk>,
   Sprow <news@sprow.co.uk> wrote:
> In article <55c19ea163News03@avisoft.f9.co.uk>,
>    Martin <News03@avisoft.f9.co.uk> wrote:
> > I have been trying to use the Cipher module v0.07 (see
> > http://www.queen.clara.net/pgp/acorn.html) to create MD5 digests from
> > simple text strings, all within a program. 
> >
> > Anyone tried anything similar?

> There's an md5 command inside !Internet now (for ROOL disc images post
> dating September 2014) which will chew a string instead of a file:

> *md5 -s "Hello"
> MD5 ("Hello") = 8b1a9953c4611296a827abf8c47804d7

> you could shell out of BASIC, run that, piping the result to a file,
> then read the result back in,

I tried that command first, and found that it ended the Basic program so
needed shelling, as you say. So I was looking for a simpler alternative.

Maybe I need to remind myself where I have an example of shelling...

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
9/19/2016 11:23:23 AM
In article <55c203da62News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <a91cfbc155.cferris@cferris.freeuk.com>,
>    <cferris@freeRemoveuk.com.invalid> wrote:
> > In message <55c19ea163News03@avisoft.f9.co.uk>
> >           Martin <News03@avisoft.f9.co.uk> wrote:

> > > I have been trying to use the Cipher module v0.07... 
[Snip]
> > > but it Data Aborts in the MD5_End SWI
> > > ->  STR     R0,[R4,#0]
> > > where r4 = &FA207FBC, hence the Data Abort, as it is in User mode.

I think the clue was 'User Mode', because this is while processing a SWI,
which I would expect to be in SVC mode.

And when I fired up my old RiscPC with 4.39, my code worked!

So could it be one of the following which is somehow corrupting the Mode?
   LDMFD   sp!,{v1-v6,pc}^ 
   LDMFD   sp!,{v1,pc}^    
   LDMFD   sp!,{a2,v1-ip,pc}^

I have tried to re-compile it - and the C parts seem to compile.
But there are two assembler bits, which fail with errors like
    Multiply or incompatibly defined symbol, in 'S11 EQU 7'
    Register symbol already defined,         in 's1 RN ip'
    
I cannot see where else they are defined, so I changed them to add Z on
the front of the names ... and it then assembled!

Still had the original problem, so changed
    LDMFD  sp!,{v1-v6,pc}^
to remove the ^ ... and it assembled and worked for my test!

I am not sure if it messes anything else up, and there are certainly some
other 32bit problems. But it certainly gives some more clues! 

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
9/19/2016 5:04:29 PM
On 19/09/2016 18:04, Martin wrote:
> And when I fired up my old RiscPC with 4.39, my code worked!
>
> So could it be one of the following which is somehow corrupting the Mode?
>    LDMFD   sp!,{v1-v6,pc}^
>    LDMFD   sp!,{v1,pc}^
>    LDMFD   sp!,{a2,v1-ip,pc}^

Those instructions aren't 32 bit safe, which could be your problem.

Are you using the latest version of the module? I'm sure there is a 
32bit safe.

> I have tried to re-compile it - and the C parts seem to compile.
> But there are two assembler bits, which fail with errors like
>     Multiply or incompatibly defined symbol, in 'S11 EQU 7'
>     Register symbol already defined,         in 's1 RN ip'
>
> I cannot see where else they are defined, so I changed them to add Z on
> the front of the names ... and it then assembled!
>
> Still had the original problem, so changed
>     LDMFD  sp!,{v1-v6,pc}^
> to remove the ^ ... and it assembled and worked for my test!

The vast majority of code (particularly compiled C) doesn't need to be 
flag preserving but the 26 bit compiler always uses flag preserving 
function wrappers. So that may work, or rather appear to work in some 
cases, but you need to examine the rest of the code to see if any of the 
callers really do need flag preservation, or if it is privileged mode 
code which is using ^ to restore mode - but it should be doing that 
within code called as part of a SWI, that is done by the SWI handler.

> I am not sure if it messes anything else up, and there are certainly some
> other 32bit problems. But it certainly gives some more clues!

If it isn't 32 bit, there are lots more changes required. Particularly 
if its a module, the V flag need to be explicitly cleared at the exit 
points to prevent the now non flag preserving code having the V flag set 
as a by-product of comparison and arithmetic instructions, and causing a 
spurious error condition and crash. That will need additional code, so 
can't just be patched.

Recompiling from source is the best route to get a 32bit module.

---druck

0
druck
9/19/2016 7:23:21 PM
In message <55c223cf5fNews03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> In article <55c203da62News03@avisoft.f9.co.uk>,
>    Martin <News03@avisoft.f9.co.uk> wrote:
>> In article <a91cfbc155.cferris@cferris.freeuk.com>,
>>    <cferris@freeRemoveuk.com.invalid> wrote:
>>> In message <55c19ea163News03@avisoft.f9.co.uk>
>>>           Martin <News03@avisoft.f9.co.uk> wrote:

>>>> I have been trying to use the Cipher module v0.07...
> [Snip]
>>>> but it Data Aborts in the MD5_End SWI
>>>> ->  STR     R0,[R4,#0]
>>>> where r4 = &FA207FBC, hence the Data Abort, as it is in User mode.

[snip]

> I am not sure if it messes anything else up, and there are certainly some
> other 32bit problems. But it certainly gives some more clues!

There are some - pc}^ - in cipher.s files (Arm code).

The I_bit/F_bit are not 32bit in the cipher.hdr.Regs.
But not sure that they are used.

I think the SetV needs two lines.
If this module isn't going to be used on say A5000 etc
might pay to update the MACROs to use msr cpsr_f,etc.

-- 
Colin Ferris Cornwall UK
0
cferris
9/19/2016 8:39:21 PM
In article <nrpdv6$23c$1@dont-email.me>,
   druck <news@druck.org.uk> wrote:
> On 19/09/2016 18:04, Martin wrote:

> Those instructions aren't 32 bit safe, which could be your problem.

Indeed.

> Are you using the latest version of the module? I'm sure there is a 
> 32bit safe.

I am using the latest one I can find, which is v0.07 (10 Aug 2004). It
has has the 32-bit header and the !Readme says for 0.06 (28 Oct 2003):
Converted to 32-bit by Paul Vigay.

> The vast majority of code (particularly compiled C) doesn't need to be
> flag preserving but the 26 bit compiler always uses flag preserving
> function wrappers. So that may work, or rather appear to work in some
> cases, but you need to examine the rest of the code to see if any of
> the callers really do need flag preservation, or if it is privileged
> mode code which is using ^ to restore mode - but it should be doing
> that within code called as part of a SWI, that is done by the SWI
> handler.

Strange thing is it was in a SWI handler, but failed in User Mode!

> If it isn't 32 bit, there are lots more changes required. Particularly
> if its a module, the V flag need to be explicitly cleared at the exit
> points to prevent the now non flag preserving code having the V flag
> set as a by-product of comparison and arithmetic instructions, and
> causing a spurious error condition and crash. That will need
> additional code, so can't just be patched.

> Recompiling from source is the best route to get a 32bit module.

That is what I have done, having removed just one ^ which fixed my test.
The results from Armalyser v0.62 show:

---------------------------------
Statistics          v0.07    New
---------------------------------
Size in words   :    4838    4010
Code            :    2578    2605
  surmised      :      84     304
  uses PSR      :       5       4
  not ARM2/3    :       3       3
  not 32 bit    :       3       2
  unpredictable :       0       0
Data            :    2260    1405
  surmised      :    1862    1023
Warnings        :      19       5
Unidentified    :       0       0
---------------------------------

so there is obviously more to be done yet!
I have 32bitted Basic/Assembler before, but not C.

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
9/19/2016 10:49:32 PM
In article <55c243668fNews03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> > Recompiling from source is the best route to get a 32bit module.

Done that, but I am wondering if the C and ObjASM options are the optimum
to be able to run on all current machines. They are

CCFlags= $(DEPEND) -c -throwback -IC:
OBJASMFlags= $(DEPEND) -throwback -quit -closeexec

Note that Cipher is a mixed ASM and C Module.

Any suggestions welcome, although it does appear to run correctly on RPC,
Iyonix and RPi (1?).

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/9/2016 10:08:55 PM
On 09/10/2016 23:08, Martin wrote:
> In article <55c243668fNews03@avisoft.f9.co.uk>,
>    Martin <News03@avisoft.f9.co.uk> wrote:
>>> Recompiling from source is the best route to get a 32bit module.
>
> Done that, but I am wondering if the C and ObjASM options are the optimum
> to be able to run on all current machines. They are
>
> CCFlags= $(DEPEND) -c -throwback -IC:
> OBJASMFlags= $(DEPEND) -throwback -quit -closeexec

CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate 32bit 
and ARMv7 safe code, the linker needs -apcs 3/32 too.

OBJASM doesn't need any flags...

> Note that Cipher is a mixed ASM and C Module.

...but you do have to manually fix any assembler, including macros.

> Any suggestions welcome, although it does appear to run correctly on RPC,
> Iyonix and RPi (1?).

The RPC is 26bit anyway, and the Iyonix and RPi1/2 are far more tolerant 
of not strictly 32bit code than the Pi3 and newer ARM boards.

---druck

0
druck
10/10/2016 2:49:50 PM
In article <ntg9q1$s3v$1@dont-email.me>, druck <news@druck.org.uk> wrote:
> On 09/10/2016 23:08, Martin wrote:
> > In article <55c243668fNews03@avisoft.f9.co.uk>, Martin
> >    <News03@avisoft.f9.co.uk> wrote:
> >>> Recompiling from source is the best route to get a 32bit module.
> >
> > Done that, but I am wondering if the C and ObjASM options are the
> > optimum to be able to run on all current machines. They are
> >
> > CCFlags= $(DEPEND) -c -throwback -IC:
> > OBJASMFlags= $(DEPEND) -throwback -quit -closeexec

> CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate 32bit 
> and ARMv7 safe code, 

That seems to all compile ok, thanks.

> the linker needs -apcs 3/32 too.

The Linker was 
    LinkFlags= -rmf -o $@
but when I made it
    LinkFlags= -rmf -o $@ -apcs 3/32
it gave
    ARM Linker: (Fatal) Multiple output types, use one of -aif, -aof, 
    -elf, -rmf, -bin, -ihf or -util 
so I removed the -rmf and it gave
    ARM Linker: (Fatal) Unrecognised option -apcs.

What have I done wrong?

> OBJASM doesn't need any flags...

> > Note that Cipher is a mixed ASM and C Module.
> ..but you do have to manually fix any assembler, including macros.

That is my aim!

> > Any suggestions welcome, although it does appear to run correctly on
> > RPC, Iyonix and RPi (1?).

> The RPC is 26bit anyway, and the Iyonix and RPi1/2 are far more
> tolerant of not strictly 32bit code than the Pi3 and newer ARM boards.

Yes, that was why I was asking, so I could try and anticipate such
problems.

Thanks for your help.

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/10/2016 3:15:35 PM
On 10/10/2016 16:15, Martin wrote:
> In article <ntg9q1$s3v$1@dont-email.me>, druck <news@druck.org.uk> wrote:
>> On 09/10/2016 23:08, Martin wrote:
>> CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate 32bit
>> and ARMv7 safe code,
>
> That seems to all compile ok, thanks.
>
>> the linker needs -apcs 3/32 too.
>
> The Linker was
>     LinkFlags= -rmf -o $@
> but when I made it
>     LinkFlags= -rmf -o $@ -apcs 3/32
> it gave
>     ARM Linker: (Fatal) Multiple output types, use one of -aif, -aof,
>     -elf, -rmf, -bin, -ihf or -util
> so I removed the -rmf and it gave
>     ARM Linker: (Fatal) Unrecognised option -apcs.
>
> What have I done wrong?

Nothing, my fault - I always use cc to link rather than the linker 
directly. If using cc you need to use the -apcs flag in both places to 
avoid errors, if using the linker directly you don't.

---druck

0
druck
10/10/2016 7:23:49 PM
In article <ntgprn$tgd$1@dont-email.me>,
   druck <news@druck.org.uk> wrote:
> > What have I done wrong?

> Nothing, my fault - I always use cc to link rather than the linker 
> directly. If using cc you need to use the -apcs flag in both places to 
> avoid errors, if using the linker directly you don't.

Thanks. Now I know what it should be I will re-read the manual to try and
understand what works!

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/10/2016 10:17:37 PM
In article <ntg9q1$s3v$1@dont-email.me>,
   druck <news@druck.org.uk> wrote:

> CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate 32bit 
> and ARMv7 safe code

I added those flags, and it seems to work well on my Iyonix.

And it worked well on my RPi 1 ... until I put alignment exceptions on,
and then it failed miserably (not suprisingly) when executing
    LDR     R4,[R12,#2]
(which has
    LDR     R4,[R12,#6]
soon after!).

This code is from the C part of the module.

Do I need another flag to avoid this?

Thanks
Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/18/2016 11:44:01 AM
In message <55d0f5b66eNews03@avisoft.f9.co.uk>
 on 18 Oct 2016 Martin  wrote:

> In article <ntg9q1$s3v$1@dont-email.me>,
>    druck <news@druck.org.uk> wrote:
> 
> > CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate 32bit 
> > and ARMv7 safe code
> 
> I added those flags, and it seems to work well on my Iyonix.
> 
> And it worked well on my RPi 1 ... until I put alignment exceptions on,
> and then it failed miserably (not suprisingly) when executing
>     LDR     R4,[R12,#2]
> (which has
>     LDR     R4,[R12,#6]
> soon after!).
> 
> This code is from the C part of the module.
> 
> Do I need another flag to avoid this?

From the documentation "-memaccess -L41" ought to avoid that situation,
though I am not sure how the compiler can really completely avoid rotated
loads because the value in R12 could be something that isn't a multiple of 4
itself, and then you'd be back to square one.  The -L22-S22 is to avoid
half-word accesses which are not available on the RISC PC.

Is your compiler up to date?  Perhaps that could be an issue?

In RiscOSM we have

CCflags = -c -depend !Depend -IC: -throwback -c99 -APCS
3/32bit/fpe2/swst/fp/nofpr -zpq40

In Impact we have

CCflags = -c -depend !Depend -C90 -APCS 3/32bit/fpe2/swst/fp/nofpr -IC:
-throwback -zpq32 

and they seem to work on all the machines out there. I don't know what half
of it is about any more though.  The -zpq things are turning off a couple of
optimisation methods which were bugged at one time or another but possibly
fixed now.  I think most of the APCS stuff is probably incorporated in the
default options of the compiler these days, and might have been of use a long
time ago.

On the other hand, none of this is module code -- just Wimp applications.

-- 
Matthew Phillips
Durham
0
Matthew
10/18/2016 4:00:44 PM
In article <45370dd155.Matthew@sinenomine.freeserve.co.uk>,
   Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> In message <55d0f5b66eNews03@avisoft.f9.co.uk>
>  on 18 Oct 2016 Martin  wrote:

> > In article <ntg9q1$s3v$1@dont-email.me>,
> >    druck <news@druck.org.uk> wrote:
> > 
> > > CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate
> > > 32bit and ARMv7 safe code
> > 
> > I added those flags, and it seems to work well on my Iyonix.
> > 
> > And it worked well on my RPi 1 ... until I put alignment exceptions
> > on, and then it failed miserably (not suprisingly) when executing
> >     LDR     R4,[R12,#2]
> > (which has
> >     LDR     R4,[R12,#6]
> > soon after!).
> > 
> > This code is from the C part of the module.
> > Do I need another flag to avoid this?

> From the documentation "-memaccess -L41" ought to avoid that situation,
> though I am not sure how the compiler can really completely avoid
> rotated loads because the value in R12 could be something that isn't a
> multiple of 4 itself, and then you'd be back to square one.  The
> -L22-S22 is to avoid half-word accesses which are not available on the
> RISC PC.

That was my reading of the docs as well. The value of r12 could be a
problem ... but in this case was word aligned. It is loaded from r0, and
may be the address of a first parm. It does loads at offsets 0,2,4,6 in
rapid succession, which looks like halfwords to me!

> Is your compiler up to date?  Perhaps that could be an issue?

It is the latest released.

> In RiscOSM we have CCflags = -c -depend !Depend -IC: -throwback -c99
> -APCS 3/32bit/fpe2/swst/fp/nofpr -zpq40

> In Impact we have CCflags = -c -depend !Depend -C90 -APCS
> 3/32bit/fpe2/swst/fp/nofpr -IC: -throwback -zpq32 

> and they seem to work on all the machines out there. I don't know what
> half of it is about any more though.  The -zpq things are turning off a
> couple of optimisation methods which were bugged at one time or another
> but possibly fixed now.  I think most of the APCS stuff is probably
> incorporated in the default options of the compiler these days, and
> might have been of use a long time ago.

I may try some of those additional ones tomorrow, but none look likely
from my reading of the docs.

> On the other hand, none of this is module code -- just Wimp
> applications.

I would hope that made little difference to the code generated.

I confess I do not understand the C code in the implicated function
de_key_idea(), which is in Cipher.Source.c.idea if anyone cares to have a
look. I wonder if something should be defined as 16bit which is using
32bit (the ReadMe implies it uses 16bit arithmetic). It can be downloaded
from http://www.queen.clara.net/pgp/cipher.zip but I also have some
(corrected) source here.

Thanks
Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/18/2016 9:23:18 PM
In message <55d12abebaNews03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> In article <45370dd155.Matthew@sinenomine.freeserve.co.uk>,
>    Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
>> In message <55d0f5b66eNews03@avisoft.f9.co.uk>
>>  on 18 Oct 2016 Martin  wrote:

>>> In article <ntg9q1$s3v$1@dont-email.me>,
>>>    druck <news@druck.org.uk> wrote:
>>> 
>>>> CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate
>>>> 32bit and ARMv7 safe code
>>> 

Are you sure that there is no ARM code - being linked in?


-- 
Colin Ferris Cornwall UK
0
cferris
10/18/2016 10:27:27 PM
In article <55d12abebaNews03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <45370dd155.Matthew@sinenomine.freeserve.co.uk>,
>    Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> > In message <55d0f5b66eNews03@avisoft.f9.co.uk>
> >  on 18 Oct 2016 Martin  wrote:
> > > In article <ntg9q1$s3v$1@dont-email.me>,
> > >    druck <news@druck.org.uk> wrote:
> > > 
> > > > CCFlags need -apcs 3/32 -memaccess -L22-S22-L41 added to generate
> > > > 32bit and ARMv7 safe code
> > > 
> > > I added those flags, and it seems to work well on my Iyonix.
> > > 
> > > And it worked well on my RPi 1 ... until I put alignment exceptions
> > > on, and then it failed miserably (not suprisingly) when executing
> > >     LDR     R4,[R12,#2]
> > > (which has
> > >     LDR     R4,[R12,#6]
> > > soon after!).
> > > 
> > > This code is from the C part of the module.
> > > Do I need another flag to avoid this?
>
> I confess I do not understand the C code in the implicated function
> de_key_idea(), which is in Cipher.Source.c.idea if anyone cares to have a
> look.

I can't see any uses of LDR /anything/ R12 (ip), and all loads look word
aligned to me. Sure you're implicating the right function?

de_key_idea
        MOV      ip,sp
        STMDB    sp!,{a1,a2,v1-v5,fp,ip,lr,pc}
        SUB      fp,ip,#4
        CMP      sp,sl
        BLMI     __rt_stkovf_split_small
        MOV      v1,#0
        MOV      v2,a1
        MOV      v4,a2
|L000234.J4.de_key_idea|
        LDR      a3,[v2,v1,LSL #2]
        BIC      a1,a3,#&ff000000
        BIC      a1,a1,#&ff0000
        BL       inv
        RSB      v5,v1,#8
        ADD      v3,v2,v1,LSL #2
        STR      a1,[v4,v5,LSL #2]
        LDR      a4,[v3,#&6c]
        BIC      a1,a4,#&ff000000
        BIC      a1,a1,#&ff0000
        BL       inv
        ADD      a4,v4,v5,LSL #2
        CMP      v1,#0
        CMPNE    v1,#8
        STR      a1,[a4,#&6c]
        LDREQ    a1,[v3,#&24]
        ADD      v1,v1,#1
        LDRNE    a1,[v3,#&48]
        RSB      a1,a1,#0
        BIC      a2,a1,#&ff000000
        BIC      a2,a2,#&ff0000
        STR      a2,[a4,#&24]
        LDREQ    a2,[v3,#&48]!
        LDRNE    a2,[v3,#&24]!
        CMP      v1,#9
        RSB      a3,a2,#0
        BIC      a1,a3,#&ff000000
        BIC      a1,a1,#&ff0000
        STR      a1,[a4,#&48]!
        BLT      |L000234.J4.de_key_idea|
        MOV      a1,#0
|L0002b0.J11.de_key_idea|
        RSB      a4,a1,#7
        ADD      a2,v2,a1,LSL #2
        LDR      a3,[a2,#&90]
        ADD      a4,v4,a4,LSL #2
        ADD      a1,a1,#1
        STR      a3,[a4,#&90]
        LDR      a2,[a2,#&b4]
        CMP      a1,#8
        STR      a2,[a4,#&b4]!
        BLT      |L0002b0.J11.de_key_idea|
        LDMDB    fp,{v1-v5,fp,sp,pc}

Sprow.

0
Sprow
10/19/2016 7:19:00 AM
On 18/10/2016 17:00, Matthew Phillips wrote:
[Memaccess stuff]

> Is your compiler up to date?  Perhaps that could be an issue?

You need version 5.56 of Norcroft or later, which you either got through 
Castle or bought from ROOL, not the old Acorn C/C++ package.

Alternatively use gcc 4 which generates ARMv7 clean code.

---druck

0
druck
10/19/2016 7:42:05 AM
In article <55d161490enews@sprow.co.uk>,
   Sprow <news@sprow.co.uk> wrote:
> In article <55d12abebaNews03@avisoft.f9.co.uk>,
>    Martin <News03@avisoft.f9.co.uk> wrote:

[Snip]

> > I confess I do not understand the C code in the implicated function
> > de_key_idea(), which is in Cipher.Source.c.idea if anyone cares to
> > have a look.

> I can't see any uses of LDR /anything/ R12 (ip), and all loads look word
> aligned to me. Sure you're implicating the right function?

Thanks Sprow - that was the kick I needed!

The function was as named in Where ... but I omitted to question it.
The abort is indeed in some assembler code, which happens to be linked in
after the C function.

It is now obvious that the cause is
		LDRW	x1,Zs1,0,mask
		LDRW	x2,Zs1,1,mask
		LDRW	x3,Zs1,2,mask
		LDRW	x4,Zs1,3,mask

where the macro LDRW is defined as
		      MACRO
$label		LDRW	$r,$from,$offset,$mask
$label		LDR	$r,[$from,#$offset << 1]
		      lower16	$r,$mask
		      MEND

.... and there is also a STRW macro, but that seems to use STRB so should
be ok.

It seems my education will have to spread a little to macros, which I
have never fully inderstood.

Sorry for the misleading question ... but I am on the right track now.

Thanks to all
Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/19/2016 10:03:04 AM
In article <55d1704eb5News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <55d161490enews@sprow.co.uk>,
>    Sprow <news@sprow.co.uk> wrote:
> > In article <55d12abebaNews03@avisoft.f9.co.uk>,
> >    Martin <News03@avisoft.f9.co.uk> wrote:
> > > I confess I do not understand the C code in the implicated function
> > > de_key_idea(), which is in Cipher.Source.c.idea if anyone cares to
> > > have a look.
> >
> > I can't see any uses of LDR /anything/ R12 (ip), and all loads look word
> > aligned to me. Sure you're implicating the right function?
>
> Thanks Sprow - that was the kick I needed!
>
> where the macro LDRW is defined as
> 		      MACRO
> $label		LDRW	$r,$from,$offset,$mask
> $label		LDR	$r,[$from,#$offset << 1]
> 		      lower16	$r,$mask
> 		      MEND

You could just copy/substitute/take inspiration from the LDHA (load halfword
from array) macro in Hdr:Macros in the DDE. For the disc environment it'll
reduce down to a nice safe aligned load and a bit of shifting,
Sprow.

0
Sprow
10/19/2016 6:28:16 PM
In article <55d19e8f5fnews@sprow.co.uk>,
   Sprow <news@sprow.co.uk> wrote:

[Snip]

> You could just copy/substitute/take inspiration from the LDHA (load
> halfword from array) macro in Hdr:Macros in the DDE. For the disc
> environment it'll reduce down to a nice safe aligned load and a bit of
> shifting, 

Thanks for that. 
I had already managed something simpler, because the offsets were 0-3
only...

		  MACRO
$label		    LDRW	$r,$from,$offset,$mask
	       ASSERT	$offset >= 0 :LAND: $offset <= 3	; ensure ok
	       IF	$offset  = 0 :LOR:  $offset  = 2	; aligned
$label		    LDR	$r,[$from,#$offset << 1]
		          lower16	$r,$mask
	       ELSE				; address needs aligning  
$label		    LDR	$r,[$from,#($offset-1) << 1 ] 	; now aligned
		          MOV	$r,$r,LSR #16	; shift xxxx.... to xxxx
	       ENDIF
		  MEND
where mask is 0xFFFF, and lower16 just ANDs with the mask.

This seems to solve my problems nicely!
And I now know a lttle more about macros.
Thanks for your prompt.

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 
0
Martin
10/19/2016 8:38:50 PM
Reply: