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

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

Assembler Help.

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

Contents

  Assembler Help. Gazza <usenet@garethlock.com> - 2012-07-10 07:09 -0700
    Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-07-10 08:46 -0700
      Re: Assembler Help. Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-07-10 18:06 +0100
        Re: Assembler Help. jgharston <jgh@arcade.demon.co.uk> - 2012-07-11 11:26 -0700
          Re: Assembler Help. cferris@freeRemoveuk.com.invalid - 2012-07-11 20:05 +0100
            Re: Assembler Help. jgharston <jgh@arcade.demon.co.uk> - 2012-07-11 15:16 -0700
            Re: Assembler Help. Steve Drain <steve@kappa.me.uk> - 2012-07-12 10:25 +0100
              Re: Assembler Help. cferris@freeRemoveuk.com.invalid - 2012-07-13 09:23 +0100
                Re: Assembler Help. Steve Drain <steve@kappa.me.uk> - 2012-07-13 11:16 +0100
                  Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-07-24 05:17 -0700
                    Re: Assembler Help. Gavin Wraith <gavin@wra1th.plus.com> - 2012-07-24 14:02 +0100
                      Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-07-24 06:49 -0700
                    Re: Assembler Help. Steve Drain <steve@kappa.me.uk> - 2012-07-24 15:03 +0100
                      Re: Assembler Help. usenet@garethlock.com - 2012-07-24 08:21 -0700
                        Re: Assembler Help. Steve Drain <steve@kappa.me.uk> - 2012-07-24 17:55 +0100
                          Re: Assembler Help. Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-03 20:26 +0100
                            Re: Assembler Help. cferris@freeRemoveuk.com.invalid - 2012-08-05 08:51 +0100
                    Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-07-24 20:04 +0100
                      Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-07-24 14:16 -0700
                        Re: Assembler Help. Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-07-24 22:34 +0100
                          Re: Assembler Help. Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-07-24 23:56 +0100
                        Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-07-25 01:42 +0100
                          Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-03 05:54 -0700
                            Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-03 17:52 +0100
                              Re: Assembler Help. "Barry Allen (news)" <evanallen@onetel.net.uk.invalid> - 2012-08-04 10:21 +0100
                              Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-04 15:57 -0700
                                Re: Assembler Help. cferris@freeRemoveuk.com.invalid - 2012-08-05 08:48 +0100
                                  Re: Assembler Help. Martin <News03@avisoft.f9.co.uk> - 2012-08-06 10:00 +0100
                                  Re: Assembler Help. Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-06 13:26 +0100
                                    Re: Assembler Help. Martin <News03@avisoft.f9.co.uk> - 2012-08-06 23:13 +0100
                                      Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-07 08:50 -0700
                                        Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-07 15:43 -0700
                                          Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-08 00:52 +0100
                                            Re: Assembler Help. usenet@garethlock.com - 2012-08-08 02:03 -0700
                                              Re: Assembler Help. jeffrey.a.doggett@gmail.com - 2012-08-08 02:19 -0700
                                              Re: Assembler Help. druck <news@druck.org.uk> - 2012-08-12 09:05 +0100
                                            Re: Assembler Help. Frank de Bruijn <zuiderduin@hotmail.com> - 2012-08-08 11:40 +0200
                                              Re: Assembler Help. Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-08 11:34 +0100
                                                Re: Assembler Help. Justin Fletcher <gerph@gerph.org> - 2012-08-09 21:19 +0100
                                                Re: Assembler Help. druck <news@druck.org.uk> - 2012-08-12 09:08 +0100
                                                  Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-14 05:17 -0700
                                                    Re: Assembler Help. Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-08-14 14:50 +0100
                                                      Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-14 15:03 +0100
                                                    Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-14 14:59 +0100
                                                      Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-15 17:01 -0700
                                                        Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-21 03:54 -0700
                                                          Re: Assembler Help. Martin <News03@avisoft.f9.co.uk> - 2012-08-21 12:27 +0100
                                                            Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-21 05:08 -0700
                                                              Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-21 05:25 -0700
                                                                Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-21 08:23 -0700
                                                          Re: Assembler Help. druck <news@druck.org.uk> - 2012-08-21 18:19 +0100
                                                            Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-21 14:20 -0700
                                                              Re: Assembler Help. cferris@freeRemoveuk.com.invalid - 2012-08-22 09:07 +0100
                                                                Re: Assembler Help. Gazza <usenet@garethlock.com> - 2012-08-22 05:28 -0700
                                                                  Re: Assembler Help. Steve Fryatt <news@stevefryatt.org.uk> - 2012-08-22 14:47 +0100
                                                              Re: Assembler Help. druck <news@druck.org.uk> - 2012-08-22 23:11 +0100
                                                                Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-29 18:36 +0100
                                                          Re: Assembler Help. Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-22 09:38 +0100
                                            Re: Assembler Help. jgh@arcade.demon.co.uk (Jonathan Graham Harston) - 2012-08-08 23:15 +0100
                                              Re: Assembler Help. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-08-09 13:59 +0100
                                                Re: Assembler Help. Steve Drain <steve@kappa.me.uk> - 2012-08-10 15:50 +0100
    Re: Assembler Help. Frank de Bruijn <zuiderduin@hotmail.com> - 2012-07-11 08:30 +0200
      Re: Assembler Help. cferris@freeRemoveuk.com.invalid - 2012-07-11 09:26 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#1954

In article <mpro.m7op9200chhio01t4@wingsandbeaks.org.uk.invalid>,
   Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk>
wrote:
> Gazza <usenet@garethlock.com> wrote:

> > So I'm performing the word aligned load, ONLY if the pointer is word
> > aligned.

> Can you not do that by checking that the bottom two bits are zero?

Precisely.

-- 
Chris Johnson

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

#1955

The following bytes were arranged on 24 Jul 2012 by Gazza :

> On Jul 24, 8:04 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
> wrote:
> > Is the value you want to divide by a power of two?  You can use the
> > shift, AND and BIC instructions to perform the equivalent of
> > division.
> ... If MOD was an instruction that returned the modulo (R2=R3 MOD 4).
> So I'm performing the word aligned load, ONLY if the pointer is word
> aligned.

I'm feeling ever so smug.  I interpreted your underlying motives
perfectly.

Probably a sign I've been trying to help you too often...

-- 
  __<^>__   Red sky in the morning: Shepherd's warning
 / _   _ \  Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1972

OK... Been getting on with a bit more, and I think I have most of the
keying in completed. There are some sections of code that I'm not sure
about and some things that I don't know how to do, so have insrted no
ops (MOV R0,R0) and some comments on what should be happening. As
usual, any help would be appreciated.

http://www.garethlock.com/mem.txt
The current version can be found at this link for those of you who are
interested.

I'd be particularly interested in Steve Revill's input if he sees
this, as ASH was originally his doing.

Thanks.

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

#1973

The following bytes were arranged on 3 Aug 2012 by Gazza :

> OK... Been getting on with a bit more, and I think I have most of the
> keying in completed. There are some sections of code that I'm not sure
> about and some things that I don't know how to do, so have insrted no
> ops (MOV R0,R0) and some comments on what should be happening. As
> usual, any help would be appreciated.

> AND R0,R0,#&FFFFFFFC

May I suggest "BIC R0,R0,#3"?  The BIC instruction (BIt Clear) does the
equivalent of AND NOT, which is useful for the common case of setting
certain bits to 0.

The MVN instruction just does the NOT without the AND.  However, you
should remember that MVN does not work the same way as CMN.  CMN takes
the negative of its second operand, but MVN just takes the inverse.
Therefore, to set R0 to -1, you use "MVN R0,#0".  But to compare R0 with
-1, you use "CMN R0,#1".

On the other hand, looking at the line above:

> ADD R0,R0,#15
> AND R0,R0,#&FFFFFFFC ; This might be the wrong way to interpret this.

Are you trying to align R0 to the next 16-byte boundary?  In that case,
you want:

ADD R0,R0,#15
BIC R0,R0,#15

> AND R2,R3,#3 ; Is R3 MOD 4 = 0?
> CMP R2,#0
> BNE ash_blkbfill_l2 ; If not, skip the check. (Word aligned load)

In general, if you ever use the instruction "CMP Rx,#0" in the middle
of a calculation, you're doing it wrong.

In most cases, including this one, you can save an instruction by using
the S suffix to set the flags:

ANDS R2,R3,#3
BNE ash_blkbfill_l2

The Z flag will be set if the contents of R2 after the AND operation are
0, which is exactly the test you were performing with the CMP
instruction.

Except I see you're not actually using the contents of R2 at all, which
means you're essentially wasting a register there.  If you're using ANDS
without any use for the destination register, you can condense it even
further to:

TST R3,#3
BNE ash_blkbfill_l2

Remember: CMP is the equivalent of SUBS without the result being stored
anywhere, TST is ANDS without a destination register, and TEQ is EORS.

> .ash_blksize
> STMFD SP!,{R1,R3}
> CMP R0,#0
> BLE ash_badblk
> MOV R3,R0
> SUB R3,R3,#4
> LDR R0,[R3],#4
> LDMFD SP!,{R1,R3}
> MOV PC,LR
> .ash_badblk
> CMP R1,#1<<31
> CMNVS R1,#1<<31
> LDMFD SP!,{R1,R3}
> MOV PC,LR

I'm not at all sure what you're trying to do here.  R3=R0, R3-=4,
R0=!R3, R3+=4?  And then you reset R3 back to its old value anyway?  And
you don't seem to be using R1 at all?

Wouldn't it be much simpler to do this:

.ash_blksize
CMP R0,#0
LDRNE R0,[R0,#-4]
CMPEQ R0,#1<<31 ; we know R0=0, so this always sets V
MOV PC,LR

Setting and clearing the V and C flags is a bit of a black art, but
there may well be a single instruction which sets the V flag if and only
if a register is 0.

> MOV R0,R0 ; R0=(R0+R1-1) AND NOT (R1-1)

Well, you're not using R1, so:

SUB R1,R1,#1
ADD R0,R0,R1
BIC R0,R0,R1

Was that really so difficult?

> MOV R0,R0 ; R3=R0 AND NOT R2.

BIC R3,R0,R2

Really?

> MOV R0,R0 ; Combine R3 & R4 to produce (xx.yy)

MOV R0,R4,R3,LSL #8

I repeat: Learning how to manipulate binary numbers is NOT optional.

Here, this is where I learned it from:

http://www.apdl.co.uk/riscworld/volume9/issue3/firstbasic/chap09.htm

-- 
  __<^>__   Red sky in the morning: Shepherd's warning
 / _   _ \  Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1975

In article <66288ab952.martin@blueyonder.co.uk>,
   Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> Was that really so difficult?

Was the above line really necessary? What was it meant to convey?

-- 
Barry A.
To reply by email:- barry d o t allen a t talktalk d o t net
Replace the d o t and a t by the usual.

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

#1979

This is my first foray into anything much more complicated than BASIC,
and it's a steep learning curve when the only resource I have access
to is a book, albeit a good one, that only deals with 26 bit, a set of
StrongHelp manuals that cover the instruction set well enough, but
provide very few examples, and heyrick's asm tutorial. I'm picking it
up slowly, and enjoying it at the same time.

Some of the coding probably could be a fair bit more economical. Again
this is down to lack of experience with the instruction set and trying
to port in my head, what was originally a BASIC listing. The trouble
being, I know what I want to achieve and I could do it in BASIC, but
it's learning how to do it economically in asm that's the hard part.

Thanks for the optimisations Martin and I'll get on to trying to
understand them before I implement them. That way I can understand
more how it works.

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

#1980

In message <31d1d536-6b1c-457a-a5f3-8ea9100548d3@f2g2000vbm.googlegrou 
ps.com>
          Gazza <usenet@garethlock.com> wrote:

[snip]

> Thanks for the optimisations Martin and I'll get on to trying to
> understand them before I implement them. That way I can understand
> more how it works.


You can make small bits of code in !Zap 'Code' mode say 6 lines.

Then use !Arm_Debug to work out what works - ref your notes - ie does 
your code do what you think it should.

!Arm_Debug 26bit -Theo v/d Boogaert - new web address.
http://members.upc.nl/t.boogaert6/

If you only have a 32bit processor - there is!DeskDebug
Weiss Niklaus- (demo/full version)

Also QDD_Bug by Adrian Lees.

Hope this is of some help
-- 
Colin Ferris Cornwall UK

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

#1985

On 05 Aug, in article <fcfc5fba52.cferris@cferris.freeuk.com>,
   <cferris@freeRemoveuk.com.invalid> wrote:
> In message <31d1d536-6b1c-457a-a5f3-8ea9100548d3@f2g2000vbm.googlegrou 
> ps.com>
>           Gazza <usenet@garethlock.com> wrote:

> [snip]

> > That way I can understand more how it works.

That is always an essential part of any programming!

[ snip some debug methods ]

<plug mode>
You can also use Reporter for debugging machine code, and particularly
suited to Basic assembler, because there are functions to make it easy. eg
    FNreport("a message",xx)    
where xx are flags for the registers you want to display.

See http://www.avisoft.f9.co.uk/ for details.

It also is invaluable for debugging normal Basic programs!
</plug mode>

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

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

#1990

cferris@freeremoveuk.com.invalid wrote:
> You can make small bits of code in !Zap 'Code' mode say 6 lines.

You can also write small bits of code directly into the BASIC command
prompt:

*BASIC
ARM BBC BASIC V (c) etc etc
> P%=&9000:    REM make sure we're assembling somewhere above PAGE which is
                   usually at &8F00
> [ADD r0,r1,r2
00009000 E1234567  ADD r0,r1,r2   <- assembler output
> [MOV pc,r14
00009004 E9876543  MOV pc,r14     <- next line, note how PC has advanced
> B%=4:C%=7:   REM r0=A%, r1=B%, etc
> PRINT USR&9000  : REM USR(address) calls the code and returns the value in r0
     11

Does USR also set A%, B%, etc to the values of registers on exit?

Theo

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

#2001

On 06 Aug, in article <Itl*23+bu@news.chiark.greenend.org.uk>,
   Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> Does USR also set A%, B%, etc to the values of registers on exit?

No. It just *returns* r0.

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

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

#2011

Had a go at implementing the changes in Martin Bazley's post. Made a
few more feature enchancements/additions too... Will post the updated
source on my server when I get in this evening.

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

#2015

On Aug 7, 4:50 pm, Gazza <use...@garethlock.com> wrote:
> Had a go at implementing the changes in Martin Bazley's post. Made a
> few more feature enchancements/additions too... Will post the updated
> source on my server when I get in this evening.

Sorry about the delay, but updated listing is now posted... Same URL
as previously posted.

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

#2016

The following bytes were arranged on 7 Aug 2012 by Gazza :

> On Aug 7, 4:50 pm, Gazza <use...@garethlock.com> wrote:
> > Had a go at implementing the changes in Martin Bazley's post. Made a
> > few more feature enchancements/additions too... Will post the updated
> > source on my server when I get in this evening.
>
> Sorry about the delay, but updated listing is now posted... Same URL
> as previously posted.

> ; Initialise the ASH subsystem. This has to be called before anything
> ; else. Except possibly to return LibASH (ASM) version information
> ; using ash_info with R0 = 0. Use ash_init_mm for use from BASIC
> ; programs (where HIMEM is available), otherwise use ash_init. There's
> ; probably a better way of doing this, but I don't know enough yet...

There is no difference between the OS_GetEnv SWI and the HIMEM keyword -
they perform exactly the same function.  Just use OS_GetEnv.

> SUB      R5,R3,#4
> LDR      R0,ash_total
> ADD      R0,R0,R5
> STR      R0,ash_total

As you are not using R5 for anything else in ash_alloc, it's a bit
wasteful to store and load it on the stack just for these two
instructions. Consider:

LDR R0,ash_total
ADD R0,R0,R3
SUB R0,R0,#4
STR R0,ash_total

> CMPVC    R4,#1<<31 ; Clear oVerflow flag.
> CMNVC    R4,#1<<31

I fail to see how this could clear anything, as both instructions are
only executed if the V flag is already clear (the VC condition code).
Fortunately, you immediately follow it with a call to XOS_Heap,
rendering these two instructions entirely pointless.

Oh, and I see you're not actually using R4 anywhere either.  May I
suggest, since you have so many spare registers, repurposing it to do
the job of ash_tmpval2?  Moving values around registers is much faster
than loading and storing them to memory, and you won't have to worry
about other functions overwriting your temporary space either.

> MOV R0,R3

You appear to be completely discarding the base address of the block,
returned in R2 from OS_Heap 2, and instead returning its size.  Have you
actually tested this code?

> MOV R0,R0 ; MOV R1,R4,R3,LSL #8 Bombs on assembly.

Ah, I see I forgot to include the grand old csap disclaimer.  That
should have been "ORR", not "MOV".

By the way, looking more closely at the comment above, I think you were
probably expecting that to multiply the version by 100.  It won't -
you'll get the major version * 256, plus the minor version.  You *could*
change it to multiply by 100 instead, but I'd really advise against it.
So if you want that, you'll have to work out how to do it for yourself.
:-)

> STMFD SP!,{R0-R2} ; Should this only push R0 & R1?

No, but it should be pushing (and pulling) R3, which is corrupted by
this function.

> CMPVC R4,#1<<31 ; Clear oVerflow flag.
> CMNVC R4,#1<<31

The mysterious V-clearing NOPs strike again.

And what's this?

> CMP R3,#1<<31 ; Unknown reason code in R0. Set oVerflow flag.
> CMNVS R3,#1<<31

What does the second instruction do?  It's only executed if the V flag
is set, but the stated purpose of the code is to set the V flag.  Either
it clears the V flag again (thus breaking the code) or it does nothing
(thus a waste of space).

> ANDS R2,R3,#3 ; Is R3 MOD 4 = 0?

My point about TST being the proper instruction for this job still
stands.

-- 
  __<^>__   "Your pet, our passion." - Purina
 / _   _ \  "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#2018

On Wednesday, 8 August 2012 00:52:14 UTC+1, Martin Bazley  wrote:
> The following bytes were arranged on 7 Aug 2012 by Gazza :
> 
> 
> 
> > On Aug 7, 4:50�pm, Gazza <use...@garethlock.com> wrote:
> 
> > > Had a go at implementing the changes in Martin Bazley's post. Made a
> 
> > > few more feature enchancements/additions too... Will post the updated
> 
> > > source on my server when I get in this evening.
> 
> >
> 
> > Sorry about the delay, but updated listing is now posted... Same URL
> 
> > as previously posted.
> 
> 
> 
> > ; Initialise the ASH subsystem. This has to be called before anything
> 
> > ; else. Except possibly to return LibASH (ASM) version information
> 
> > ; using ash_info with R0 = 0. Use ash_init_mm for use from BASIC
> 
> > ; programs (where HIMEM is available), otherwise use ash_init. There's
> 
> > ; probably a better way of doing this, but I don't know enough yet...
> 
> 
> 
> There is no difference between the OS_GetEnv SWI and the HIMEM keyword -
> 
> they perform exactly the same function.  Just use OS_GetEnv.
> 
> 
> 
> > SUB      R5,R3,#4
> 
> > LDR      R0,ash_total
> 
> > ADD      R0,R0,R5
> 
> > STR      R0,ash_total
> 
> 
> 
> As you are not using R5 for anything else in ash_alloc, it's a bit
> 
> wasteful to store and load it on the stack just for these two
> 
> instructions. Consider:
> 
> 
> 
> LDR R0,ash_total
> 
> ADD R0,R0,R3
> 
> SUB R0,R0,#4
> 
> STR R0,ash_total
> 
> 
> 
> > CMPVC    R4,#1<<31 ; Clear oVerflow flag.
> 
> > CMNVC    R4,#1<<31
> 
> 
> 
> I fail to see how this could clear anything, as both instructions are
> 
> only executed if the V flag is already clear (the VC condition code).
> 
> Fortunately, you immediately follow it with a call to XOS_Heap,
> 
> rendering these two instructions entirely pointless.
> 
> 
> 
> Oh, and I see you're not actually using R4 anywhere either.  May I
> 
> suggest, since you have so many spare registers, repurposing it to do
> 
> the job of ash_tmpval2?  Moving values around registers is much faster
> 
> than loading and storing them to memory, and you won't have to worry
> 
> about other functions overwriting your temporary space either.
> 
> 
> 
> > MOV R0,R3
> 
> 
> 
> You appear to be completely discarding the base address of the block,
> 
> returned in R2 from OS_Heap 2, and instead returning its size.  Have you
> 
> actually tested this code?
> 
> 
> 
> > MOV R0,R0 ; MOV R1,R4,R3,LSL #8 Bombs on assembly.
> 
> 
> 
> Ah, I see I forgot to include the grand old csap disclaimer.  That
> 
> should have been "ORR", not "MOV".
> 
> 
> 
> By the way, looking more closely at the comment above, I think you were
> 
> probably expecting that to multiply the version by 100.  It won't -
> 
> you'll get the major version * 256, plus the minor version.  You *could*
> 
> change it to multiply by 100 instead, but I'd really advise against it.
> 
> So if you want that, you'll have to work out how to do it for yourself.
> 
> :-)
> 
> 
> 
> > STMFD SP!,{R0-R2} ; Should this only push R0 & R1?
> 
> 
> 
> No, but it should be pushing (and pulling) R3, which is corrupted by
> 
> this function.
> 
> 
> 
> > CMPVC R4,#1<<31 ; Clear oVerflow flag.
> 
> > CMNVC R4,#1<<31
> 
> 
> 
> The mysterious V-clearing NOPs strike again.
> 
> 
> 
> And what's this?
> 
> 
> 
> > CMP R3,#1<<31 ; Unknown reason code in R0. Set oVerflow flag.
> 
> > CMNVS R3,#1<<31
> 
> 
> 
> What does the second instruction do?  It's only executed if the V flag
> 
> is set, but the stated purpose of the code is to set the V flag.  Either
> 
> it clears the V flag again (thus breaking the code) or it does nothing
> 
> (thus a waste of space).
> 
> 
> 
> > ANDS R2,R3,#3 ; Is R3 MOD 4 = 0?
> 
> 
> 
> My point about TST being the proper instruction for this job still
> 
> stands.

CMP   Rx,#1<<31
CMNVS Rx,#1<<31

oops...

Should have been...

CMP   Rx,#1<<31
CMNVC Rx,#1<<31

As from http://www.heyrick.co.uk/assembler/psr.html. As for clearing the oVerflow flag, that I got from a post further up this topic. As for everything else, I'm still an assembler novice, so mistakes are an essential part of learning.

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

#2019

 
> CMPVC    R4,#1<<31 ; Clear oVerflow flag.
> CMNVC    R4,#1<<31

I find that the quickest way to clear the V flag is:

ADDS R0,R0,#0

Yes, it destroys the others as well, but usually doesn't matter.

Jeff

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

#2067

On 08/08/2012 10:03, usenet@garethlock.com wrote:
> Should have been...
>
> CMP   Rx,#1<<31
> CMNVC Rx,#1<<31

These days I prefer to use explicit flag setting or clearing using MSR 
cprs_f instructions rather remember such arcane constructs for pre-ARM6 
compatibility.

---druck

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

#2020

In article <f8e3bfbb52.martin@blueyonder.co.uk>,
   Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> The following bytes were arranged on 7 Aug 2012 by Gazza :

> > CMPVC    R4,#1<<31 ; Clear oVerflow flag.
> > CMNVC    R4,#1<<31

> I fail to see how this could clear anything,

It doesn't. It SETS the overflow flag. See my earlier message in this
thread.

The quickest way to clear the overflow flag is CMP Rx,#0.

Regards,
Frank

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

#2023

Frank de Bruijn <zuiderduin@hotmail.com> wrote:

>In article <f8e3bfbb52.martin@blueyonder.co.uk>,
>   Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
>> The following bytes were arranged on 7 Aug 2012 by Gazza :
>
>> > CMPVC    R4,#1<<31 ; Clear oVerflow flag.
>> > CMNVC    R4,#1<<31
>
>> I fail to see how this could clear anything,
>
>It doesn't. It SETS the overflow flag. See my earlier message in this
>thread.

Worse even than no comments are comments that are wrong...

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

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

#2043

On Wed, 8 Aug 2012, Jeremy Nicoll - news posts wrote:

> Frank de Bruijn <zuiderduin@hotmail.com> wrote:
>
>> In article <f8e3bfbb52.martin@blueyonder.co.uk>,
>>   Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
>>> The following bytes were arranged on 7 Aug 2012 by Gazza :
>>
>>>> CMPVC    R4,#1<<31 ; Clear oVerflow flag.
>>>> CMNVC    R4,#1<<31
>>
>>> I fail to see how this could clear anything,
>>
>> It doesn't. It SETS the overflow flag. See my earlier message in this
>> thread.
>
> Worse even than no comments are comments that are wrong...

Wrong.

Comments that are wrong are confusing, but they show you the way that the 
author was thinking. Where what comments describe differs from what is 
intended or implemented is a clear indication of a problem - either in the 
code or in the thoughts of the author. Obviously you should endeavour to 
write correct comments - you would not try to write wrong ones - but the 
existance of comments, even when wrong, is still an improvement over no 
comments at all (within limits, of course).

-- 
Gerph <http://gerph.org/>
... It's the beginning of the End; you want things to go faster.
     It's the beginning of the End; now everything's too slow for you.

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

#2068

On 08/08/2012 11:34, Jeremy Nicoll - news posts wrote:
> Frank de Bruijn <zuiderduin@hotmail.com> wrote:
>
>> In article <f8e3bfbb52.martin@blueyonder.co.uk>,
>>    Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
>>> The following bytes were arranged on 7 Aug 2012 by Gazza :
>>
>>>> CMPVC    R4,#1<<31 ; Clear oVerflow flag.
>>>> CMNVC    R4,#1<<31
>>
>>> I fail to see how this could clear anything,
>>
>> It doesn't. It SETS the overflow flag. See my earlier message in this
>> thread.
>
> Worse even than no comments are comments that are wrong...

No, its the code that is wrong, and the comment alerts us to that.

---druck

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web