Hi Jay,

>   MOV R0,#5
>   CMP R0,#10
>
> Subtracting 10 from 5 should underflow.  I always view CMP as a subtract

Both correct.  CMP is *exactly* just SUBS without a destination register.

> I have noticed before that I have to invert the condition in a branch; BCS
<=> BCC.
> I can live with that too.

Well you should avoid BCC/BCS except (a) after ADD and (b) after shift (e.g
MOV with ASL).  In both cases the results are well-defined on any CPU.
Using BCC/BCS after a CMP is a bit of an abuse - you should use BHS or BLO
instead; they produce the same machine code but the mnemonics match the
"compare" concept rather than the "test the result" concept.  The only
"hole" here is that there is no equivalent BBC/BBS for use after SUB (branch
if borrow clear/set), so yeah you need to use BCC/BCS and remember that it's
opposite to certain other CPUs.  Or use BHS/BLO since SUB == CMP, and that
works on other CPUs too.

> What I wonder about is the BHI/BLS instructions which test the carry
> flag in combination.  The manual says:
>
>    HI   C set and Z clear      Higher (unsigned <= )
>    LS   C clear or Z set       Lower or same (unsigned <= )
>
> These HI/LS definitions are correct for a "carry-inverted-on-subtract"
> machine, since CMP is a subtract.  The above CMP should result in BLS
> branch taken.

And so it does - borrow is set, carry is clear, so BLS is taken.  (Except I
don't like the term "carry-inverted-on-subtract" since in this case there is
*no* inverter in the hardware, while a carry = borrow architecture needs an
inverter after the carry output on subtract!  Let's call them carry = borrow
and carry = !borrow architectures.)

> The problem is that BHI/BLS are incorrect after an addition.

Maybe there's a subtlety of the English language here, but to me it seems
wrong to ask "which number is higher" after doing an ADD.  The mnemonics
like BHI,BLO,BGE,BLT are all intended to follow CMP.  Now I do take the
point that sometimes you might want to say:

ADD A and B
Branch if !C && !Z
-or-
Branch if C || Z

But in all my years of asm programming I haven't come across a case where I
needed this.  Is there a case where you've needed this precise behaviour
after an ADD?  The behaviour is like saying "branch if there's a wraparound
or if both inputs are zero" (and its inverse).

Note that equivalently, on a carry-is-borrow architecture, you might need

ADD A and B
Branch if C && !Z
-or-
Branch if !C || Z

The behaviour here is like saying "branch if there's a wraparound unless
it's a wraparound to exactly 2^32" - and that's actually useful in MOD (2^32
+ 1) arithmetic.  But these operations are not available on a carry = borrow
architecture.  Swings and roundabouts.

In either case, the mnemonics don't match the operation, so you'd need to
comment code that used them pretty damned carefully.

>  If you do:
>
>   MOV  R0,#5
>   ADDS R0,#10
>
> The carry flag will be clear, and so a BLS will be taken.  Since the
> result is not "lower or same" it seems incorrect to me.

Ah ... I see what you're saying now.  The idea that BLO/BLS/BHI/BHS are
useful after an ADD in the way you say they are has simply never occurred to
me before - I've learned something here.

Unfortunately, the idea doesn't work!

On the other architecture, if I do

MOV R0,#0
ADDS R0,#10

The carry flag will be clear and so a BLS will *not* be taken.  Since the
result *is* "lower or same" that's incorrect to.  The reason is that the Z
flag, which in a CMP indicates the "same" condition, doesn't indicate
anything of the sort after an ADD.  So the problem is (ab)using BLS/BHI
after an ADD.  It's just not a valid thing to do in either case - and it's
scary because it *almost* works on the other architecture and traps you into
using it :-)

> The moral is: only use BHI/BLS after a subtract or compare, not after
> an addition.

True.  Conceptually you should only use BHI/BLS after a compare, but I think
it's acceptable on any CPU to assume that CMP is the same as a SUB.

> Also, the aliases for BCC/BCS: BLO/BHS are incorrect after addition.  If
this were not
> a carry-inverted machine, these branches would be correct after both
addition and
> subtraction.

No, the moral is don't use BLO/BHS after an addition because it's a
conceptual mismatch and falls down on *any* architecture if you use BLS or
BHI instead (which I suspect would be easily done and might lead to very
nasty intermittent bugs).  Use BCC/BCS after ADD instead (conceptually
clean) and forget about BLS/BHI after ADD - these tests simply aren't
available on *any* CPU.  As Yoda might say, you must unlearn the idea that
BLO/BLS/BHI/BHS are meaningful after an ADD.

Other conclusions:

1. Carry-inverted is not a good name if you're hardware-cogniscant - carry =
borrow and carry = !borrow is better
2. Assemblers should provide BBC/BBS for use after SUB to test the state of
the borrow flag (these are of course just mnemonics for BCC/BCS, and on the
ARM this extends to general condition codes BC = CS and BS = CC).

Of course if we implemented (2) we'd have yet another group of people saying
"why doesn't BBC work after ADD" :-)

Eddie

Hi,

I'd like to connect the GBA to a GPS receiver through the serial port
of the MBV2 cable. The MBV2 FAQ says:

"In order for the MBV2 to transmit serial data out the pin 9 serial
connector, pin 7 must be held high (+5v to +12v). This is normally
accomplished by enabling hardware handshaking on a PC serial
interface. This upgrade supports standard UART transmit/receive and
hardware handshaking from PC->GBA. (i.e. GBA can wait until PC is
ready to accept data.) Handshaking from GBA->PC is not supported due
to hardware limitations. (i.e. PC will not wait until GBA is ready. It
can send data to GBA at any time.)"

The way this is written, it sounds like holding pin 7 high is not
necessary if I only want to send data from the GPS receiver to the
GBA. Is this true? The serial cable for my GPS receiver doesn't
connect pin 7 to anything (it only uses send, receive and ground).

Thanks,
Borislav

i cant reproduce it either so i probably forgot the s bit or something

anyway, cheers all



----- Original Message -----
From: "Chris Hayton" <chayton@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, April 03, 2003 2:27 AM
Subject: RE: [gbadev] Re: The carry flag


> > Can you justify why the carry flag should be set in this case?
> >
> > >   mov r10,#0x7f000000
> > >   mov r11,#0x1fc00000
> > >   adds r12,r10,r11,LSL #2 (0x7f00_0000+0x7F00_0000==0xfe00_0000),
carry
> > > flag set !?!?
>
> This really perplexed me so I tried it out myself as a sanity check.
> I was unable to reproduce this behaviour either in VBA or on the hardware.
>
> ?!?
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Given the title of this list, who cares about SGADE or GB32? I sure don't.
Oh yeah, HAM doesn't compile for PS2, Xbox, or GC either...so it is pretty
limited in that respect, I guess...


Jonathan S. Harbour
http://www.jharbour.com



-----Original Message-----
From: tharo@... [mailto:tharo@...]
Sent: Wednesday, April 02, 2003 3:44 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] devkit advance and SGADE and Ham



HAM ist just a simply GCC function collection and it is still not
compatible whith something other as an gba ARM. No SGATE, no GB32.

greets
Tharo Herberg
devgba.de

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Thu, Apr 03, 2003 at 02:28:54AM +0100, Eddie Edwards wrote:
> Jay wrote:
>
> > I confirmed that this is does occur (at least in the VisualBoy emulator).
>
> Oh right an EMULATOR gives a result that doesn't match the ARM docs and
> that's confirmation of a problem with the ARM?!  Gimme a break.

OK, I can't reproduce it now with the same conditions as before, so I
retract my complaint.  If I investigate again, I will confirm on
actual hardware.  It may well be that the emulator is wrong, in which
case I need to consider my development platform.

> Morten wrote:
>
> > of course this might very well be purely academic, but the result is still
> > incorrect regardless of how you turn it. ((0-0)+0+(c)) should never result
> > in 1. as for whether you can work around it, that is a different question.
> > but the fact is that the result is incorrect.
>
> You're simply labouring under a misunderstanding of how carry flags work.
> The only thing incorrect here is following SUBS with ADC.  There is no
> meaning to this instruction sequence.
>
> Carry is only defined on ADD.  SUB defines borrow, and borrow is mapped into
> the C flag one of two possible ways.  To say that ((0-0)+0+(c)) even has
> *meaning* is to make an unwarranted assumption about how this mapping is
> done.  Carry and borrow are two distinct concepts, and to treat them as the
> same in code is incorrect.  It is your code that is wrong, *not* the CPU.

I agree that the SUBS,ADC sequence is unlikely and inconsequential.

I have no problem with how carry(borrow) works for multi-precision
arithmetic.

However it does confuse a programmer familiar with different
architectures to do:

    MOV R0,#5
    CMP R0,#10

and not have the carry set.  Subtracting 10 from 5 should underflow.
I always view CMP as a subtract, and I am accustomed to underflow
setting carry.  I have noticed before that I have to invert the
condition in a branch; BCS <=> BCC.  I can live with that too.  To
make the code more readable, I have adopted the habit of using BPL/BMI
for common compares unless I *really* need to test the carry.  The
sign flag is consistent after addition and subtraction.

What I wonder about is the BHI/BLS instructions which test the carry
flag in combination.  The manual says:

    HI   C set and Z clear      Higher (unsigned <= )
    LS   C clear or Z set       Lower or same (unsigned <= )

These HI/LS definitions are correct for a "carry-inverted-on-subtract"
machine, since CMP is a subtract.  The above CMP should result in BLS
branch taken.

The problem is that BHI/BLS are incorrect after an addition.  If you
do:

    MOV  R0,#5
    ADDS R0,#10

The carry flag will be clear, and so a BLS will be taken.  Since the
result is not "lower or same" it seems incorrect to me.

The moral is: only use BHI/BLS after a subtract or compare, not after
an addition.  Also, the aliases for BCC/BCS: BLO/BHS are incorrect
after addition.  If this were not a carry-inverted machine, these
branches would be correct after both addition and subtraction.

--
Jay Dresser /
jay
@
dresserfamily
.
org

I'm using HAM exclusively for GBA development. I ignore the Hamlib for the
most part and compile any public domain GBA code with it, including program
I write myself. It's 100% compatible with DevKit-Adv in that respect, but is
also a very easy one-click install and comes with a nice custom editor.
Check it out at www.ngine.de and on the hamdev list.


Jonathan S. Harbour
http://www.jharbour.com



-----Original Message-----
From: Bob Sabiston [mailto:bob@...]
Sent: Tuesday, April 01, 2003 2:21 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] devkit advance and SGADE and Ham



Hello,
    I messed around with GBA development about a year ago, and I used
this thing called HAM.  Is that still around?  Is it compatible with
devkit advance and SGADE?  I'd like to do this on a mac.  Is the code I
wrote using HAM unusable?  I'm unclear as to the relationship between
these libraries/kits/whatever.

Thanks for any info!
Bob

Is there a quick and simple test for detecting the SP version ? over the
older GBA? I have a help page screen that lists controls for GBA, and wish
to display the SP image instead of the GBA image. Its cosmetic, but still
adds a nice small touch.

thanks

bollo

On Wednesday 02 April 2003 18:58, Eddie Edwards wrote:
> > you completely missed my point. i was pointing out the problem with
> > operating the carry bit in this manner.
>
> You haven't pointed out any problem at all.  What *is* the problem with
> operating the carry bit in this manner?
>
> If there's a genuine problem with the ARM architecture that has somehow
> gone unnoticed for 15 years I'd like to know what it is.

maybe an old speccy owner that still cant resist any 6502-ish behaviour no
matter what? :o)

gpz

On Wednesday 02 April 2003 17:42, Emanuel Schleussinger wrote:

> As far as GP32 support goes, I don't know, never looked into it. SGADE is
> something like HAMlib, only completely free (nice!) and structured
> differently.

"supporting" the gp32 is a matter of new linkerscript and crt0 (which are both
available on the net in several variations). no special gcc is needed, i am
using the compiler from devkitadv myself. there are also libraries, for
example "pogolib" (dont have the url handy, sorry)...and ofcoz the "official"
libraries from gamepark, which are free.

so in essence, using HAM for gp32 deving might be well possible (minus HAMlib
ofcoz, unless you port it :=))

gpz

> Can you justify why the carry flag should be set in this case?
>
> >   mov r10,#0x7f000000
> >   mov r11,#0x1fc00000
> >   adds r12,r10,r11,LSL #2 (0x7f00_0000+0x7F00_0000==0xfe00_0000), carry
> > flag set !?!?

This really perplexed me so I tried it out myself as a sanity check.
I was unable to reproduce this behaviour either in VBA or on the hardware.

?!?

Morten wrote:

> of course this might very well be purely academic, but the result is still
> incorrect regardless of how you turn it. ((0-0)+0+(c)) should never result
> in 1. as for whether you can work around it, that is a different question.
> but the fact is that the result is incorrect.

You're simply labouring under a misunderstanding of how carry flags work.
The only thing incorrect here is following SUBS with ADC.  There is no
meaning to this instruction sequence.

Carry is only defined on ADD.  SUB defines borrow, and borrow is mapped into
the C flag one of two possible ways.  To say that ((0-0)+0+(c)) even has
*meaning* is to make an unwarranted assumption about how this mapping is
done.  Carry and borrow are two distinct concepts, and to treat them as the
same in code is incorrect.  It is your code that is wrong, *not* the CPU.

It's just like Damian said - it's an arbitrary choice like big-endian vs
little-endian.  Except that there are some asm tricks that are possible in
little-endian that aren't possible in big-endian and vice versa.  I *hoped*
I was going to learn something and find out that there's a trick you can do
in carry = borrow systems that you can't do in carry = !borrow systems, but
I fear I'm going to be disappointed.  I wasn't meaning to debate this with
you, I just wanted to know if you had any use for that sequence or if it was
just a contrived example.

Jay wrote:

> I confirmed that this is does occur (at least in the VisualBoy emulator).

Oh right an EMULATOR gives a result that doesn't match the ARM docs and
that's confirmation of a problem with the ARM?!  Gimme a break.

I agree that it's puzzling to find the carry flag set after Morten's first
sequence:

   mov r10,#0x7f000000
   mov r11,#0x1fc00000
   adds r12,r10,r11,LSL #2

But I just tested it on an Acorn ARM machine and it doesn't.  It gives C = 0
as you would expect.  And C = 1 if you do LSL #3, again, as you would
expect.

Can anyone confirm Morten's result on an actual GBA?

On Wed, Apr 02, 2003 at 05:58:48PM +0100, Eddie Edwards wrote:
> > you completely missed my point. i was pointing out the problem with
> > operating the carry bit in this manner.
>
> You haven't pointed out any problem at all.  What *is* the problem with
> operating the carry bit in this manner?
>
> If there's a genuine problem with the ARM architecture that has somehow gone
> unnoticed for 15 years I'd like to know what it is.

Can you justify why the carry flag should be set in this case?

>   mov r10,#0x7f000000
>   mov r11,#0x1fc00000
>   adds r12,r10,r11,LSL #2 (0x7f00_0000+0x7F00_0000==0xfe00_0000), carry
> flag set !?!?

I confirmed that this is does occur (at least in the VisualBoy
emulator).  This is not right.  The ARM manual says that the carry may
be set by the output of the barrel shifter on logical instructions,
but is set by the ALU on arithmetic instructions.  In this case there
is neither a carry from the shift or the addition.

I tried the case of:

    mov r10,#0x7f000000
    mov r11,#0x7f000000
    adds r12,r10,r11

which results in the same final operands and it works correctly, so
the problem seems shift related.

Bizarre.  When should I trust that the CPU will set the flag correctly
and when not?  Does anyone know if this is documented, and is there a
description of what class of operands it fails on?  It would be hard
to believe it has gone unnoticed for 15 years.

--
Jay Dresser /
gbadev
@
dresserfamily
.
org

--- In gbadev@yahoogroups.com, "Morten Pedersen" <escapekey@s...> wrote:
>
> of course this might very well be purely academic, but the result
> is still incorrect regardless of how you turn it. ((0-0)+0+(c))
> should never result in 1.

Academically, does Peano arithmetic define 'c'?

What's incorrect academically is to use the carry flag for anything
other than carrying from less significant to more significant place
values.  Starting again at the lowest place requires resetting the
carry, that is, using SUB or ADD instead of SBC or ADC.

It's like claiming that little-endian storage of integers is incorrect
because the English language writes them big-endian.

--
Damian

of course this might very well be purely academic, but the result is still
incorrect regardless of how you turn it. ((0-0)+0+(c)) should never result
in 1. as for whether you can work around it, that is a different question.
but the fact is that the result is incorrect.


----- Original Message -----
From: "Eddie Edwards" <eddie@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, April 02, 2003 5:58 PM
Subject: RE: [gbadev] Re: The carry flag


> > you completely missed my point. i was pointing out the problem with
> > operating the carry bit in this manner.
>
> You haven't pointed out any problem at all.  What *is* the problem with
> operating the carry bit in this manner?
>
> If there's a genuine problem with the ARM architecture that has somehow
gone
> unnoticed for 15 years I'd like to know what it is.
>
> Eddie
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> you completely missed my point. i was pointing out the problem with
> operating the carry bit in this manner.

You haven't pointed out any problem at all.  What *is* the problem with
operating the carry bit in this manner?

If there's a genuine problem with the ARM architecture that has somehow gone
unnoticed for 15 years I'd like to know what it is.

Eddie

--- In gbadev@yahoogroups.com, Greg Wogan-Browne <wogan@i...> wrote:
> Ideally there would be a way to make the cygwin gcc compile agb
> stuff (ie, compile my own devkit advance that can also compile ix86)

Here's what I do, which works on devkitadv R4 and devkitadv R5 beta:

1. Put devkitadv in PATH (one batch file)
2. Put mingw in PATH in front of devkitadv (another batch file)
3. 'gcc' to compile for Win32; 'arm-agb-elf-gcc' to compile for GBA

--
Damian

On Wednesday 02 April 2003 12:44, tharo@... wrote:
> HAM ist just a simply GCC function collection and it is still not
> compatible whith something other as an gba ARM. No SGATE, no GB32.

whoa :-) hold on , there is some big confusion here...

Hi,

this is Emanuel, I develop HAM, you can get it at http://www.ngine.de . HAM is
a product that consists of many things, it is by no means just a library:

1) A compiler tool chain, in some ways similar to devkit advance, and of
course compatible. The compiler tool chain is a normal, GCC based chain that
has no significant differences to devkitadvance (however, I am not sure about
the crt's of the latest versions). Lots of people compile devkitadvance
sources using HAM only as a compiler chain. The latest version is based off
GCC 3.2.2 / GDB 5.3 etc, available for Linux and Windows, and supports ASM, C
and C++, ARM,thumb and interworked.

2) An automated makefile environment that takes the pain out of getting your
programs to link / compile / binfix / send / flash correctly. read the HAMdoc
about it here:
http://www.ngine.de/hamdoc/targets.html#targets
This one also allows to easily use a graphical source code debugger that
automatically links up to VBA yb simply compiling your programs using "make
gdb"

3) All major tools already officially bundled and integrated into the build
system: vba, gfx2gba, krawall, and soon tUMEric

4) A visual IDE called VisualHAM that allows to compile/send/etc and edit
source code, incl. Project management console, intellisense etc.

Until here, nothing is HAM specific really. You can install HAM and use it
happily without this (many people getting more profound do this, obviously)

5) HAMlib
A highlevel library that adds an abstraction layer to the hardware for
programmers that are not familiar with low level C programming. Lots of work
has gone into this, and it now supports almost anything you could do with the
GBA hardware, with the exception of SIO. It also has its own memory
management, and the most extensive free tile support library that I am aware
of. HAMlib is shareware, and available as a freeware version with a 90 frames
intro screen.
Using this lib does not make your game incompatible with devkitadvance, if you
link the library and have the includes available, you can use it with that,
too.

HAMlib is also fully documented here: http://www.ngine.de/hamdoc/

As far as GP32 support goes, I don't know, never looked into it. SGADE is
something like HAMlib, only completely free (nice!) and structured
differently.

Hope this clears things up a bit
Emanuel
>
> greets
> Tharo Herberg
> devgba.de
>
> Bob Sabiston <bob@...> schrieb am 01.04.2003, 23:20:50:
> > Hello,
> > &nbsp;&nbsp; I messed around with GBA development about a year ago, and I
> > used this thing called HAM.&nbsp; Is that still around?&nbsp; Is it
> > compatible with devkit advance and SGADE?&nbsp; I'd like to do this on a
> > mac.&nbsp; Is the code I wrote using HAM unusable?&nbsp; I'm unclear as
> > to the relationship between these libraries/kits/whatever.
> >
> > Thanks for any info!
> > Bob
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Sponsor
> >
> >
> >   ADVERTISEMENT
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

HAM ist just a simply GCC function collection and it is still not
compatible whith something other as an gba ARM. No SGATE, no GB32.

greets
Tharo Herberg
devgba.de

Bob Sabiston <bob@...> schrieb am 01.04.2003, 23:20:50:
>
>
>
>
>
> Hello,
> &nbsp;&nbsp; I messed around with GBA development about a year ago, and I used
> this thing called HAM.&nbsp; Is that still around?&nbsp; Is it compatible with
> devkit advance and SGADE?&nbsp; I'd like to do this on a mac.&nbsp; Is the
code I
> wrote using HAM unusable?&nbsp; I'm unclear as to the relationship between
> these libraries/kits/whatever.
>
> Thanks for any info!
> Bob
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Sponsor
>
>
>   ADVERTISEMENT
>
>
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I think I know what the problem is.  Yesterday, I was working on Beta-3,
comparing the latest Jeff F lnkscript and my new linkscript to see if I left
out anything important, and noticed that i had forgotten to add an
EXCLUDE_FILE(*.iwram.o) to the .text section.  So, the .text section of your
file is probably getting written to the .text section before it gets to the
.iwram section.

I am currently writing regression tests for all the features of devkit
advance, so in the future it will be easier to see when things break.

I think that the maintainability and features of the new lnkscript and
crt0.S will be worth the bugs I've introduced during this beta period ^_^

Hmm, it just occured to me that I could write a tool which parses the output
of nm and gives you a summary of your image that is taylored for the gba
developer.  Such a tool could also tell if anything was screwed up, so it
could be used to create my regression tests.  I've been looking for a way to
warn the programmer if they are using ewram overlays and multiboot at the
same time! (i've decided that the results are 'undefined')

----- Original Message -----
From: "Damian Yerrick" <d_yerrick@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, April 02, 2003 1:38 AM
Subject: [gbadev] Devkit Advance R5 Beta 2 and .text.iwram.o


> Apparently, Devkit Advance R5 Beta 2 (which just popped up on
> SourceForge.net) doesn't recognize "siw.text.iwram.o" and
> "gbmxr.text.iwram.o" as object files whose contents belong in
> IWRAM.

That is odd, I specifically added/fixed that support between beta and
beta-2.  This may be an example of me "fixing" something which looks wrong
because I have not looked at it in 2 years.

> If placing code into IWRAM by naming the object file *.iwram.o is
> no longer supported, what is the recommended method to place code
> into IWRAM in devkitadv R5?  Or is this a known bug in beta 2?

It is definitely supported.  This week I am looking at a bunch of existing
code and methods and making sure that they still work.  I've been trying to
refine *.iwram.o support, but I did not start really messing with it until
after I released beta-2

> --
> Damian
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

Damn, I was hoping I wasn't going to have to do that - Ideally there would
be a way to make the cygwin gcc compile agb stuff (ie, compile my own
devkit advance that can also compile ix86)

Anyway, I tried the below, and GCC gives:
arm-agb-elf-gcc: installation problem, cannot exec `cc1': No such file or
directory

As far as I know cc1 isn't even part of devkitadv, yes?

I'm using R4 by the way...

At 20:44 2003-03-31, you wrote:
>I have the same setup and solved it like this:
>
>I have this in a include file which I include in all my makefiles, which
>contains:
>
>DEVKITADV_DIR = $(GBADEV_DIR)/devkitadv
>
>CC         =   $(DEVKITADV_DIR)/bin/arm-agb-elf-gcc
>AS         =   $(DEVKITADV_DIR)/bin/arm-agb-elf-as
>AR           =   $(DEVKITADV_DIR)/bin/arm-agb-elf-ar
>LD           =   $(DEVKITADV_DIR)/bin/arm-agb-elf-ld
>CPP        =   $(DEVKITADV_DIR)/bin/arm-agb-elf-cpp
>OBJCOPY    =   $(DEVKITADV_DIR)/bin/arm-agb-elf-objcopy
>
>And then in the makefile I just do:
>
>include /gbadev/Makefile_win_gcc3.inc
>
>$(TARGET_BIN): $(TARGET_ELF)
>         $(OBJCOPY) -v -O binary $< $@
>
>$(TARGET_ELF): $(.OFILES) $(LIBGCCDIR)/crtbegin.o $(LIBGCCDIR)/crtend.o
>Makefile data/libdata.a
>         $(CC) -g -o $@ $(.OFILES) $(LIBGCCDIR)/crtbegin.o
>$(LIBGCCDIR)/crtend.o $(LDFLAGS)
>
>Offcourse this are just snippets, but you get the idea I hope
>
>HTH,
>Willem
>
>
>
>-----Original Message-----
>From: Greg Wogan-Browne [mailto:wogan@...]
>Sent: 31 March 2003 10:59
>To: gbadev@yahoogroups.com
>Subject: [gbadev] GCC ix86 & ARM Coexisting?
>
>
>
>Hi
>
>I've installed Cygwin, which includes GCC on my WinXP box, and have
>successfully used it to compile PC programs. I want to keep this state
>of
>affairs, but I also want to be able to compile AGB programs. Installing
>DevKitAdv means changing paths and other env vars which breaks my
>existing
>Cygwin install (as far as I know).
>
>Can anyone give me some hints on how to set this up gracefully so that
>they
>both co-exist with eachother nicely? Cygwin includes some GCC libraries
>for
>ARM-AGB-ELF, which leads me to think that there is a way of getting
>Cygwin's GCC to compile AGB programs.
>
>Any help or links to good documentation would be appreciated,
>
>Greg Wogan-Browne
>wogan @ iinet.net.au
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to
>http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Apparently, Devkit Advance R5 Beta 2 (which just popped up on
SourceForge.net) doesn't recognize "siw.text.iwram.o" and
"gbmxr.text.iwram.o" as object files whose contents belong in
IWRAM.

I have an object file called siw.text.iwram.o which contains one
function set_palram_green().  I have another object file called
sew.o which contains main().  When I link them together and run
|objdump -x| on the resulting ELF file, I get this in the symbol
table:

08000298 g       .text  00000010 set_palram_green

Clearly, the link script is not catching the instruction in the
object file's name when deciding where to put set_palram_green().

If placing code into IWRAM by naming the object file *.iwram.o is
no longer supported, what is the recommended method to place code
into IWRAM in devkitadv R5?  Or is this a known bug in beta 2?

--
Damian

> > sub was infact a + ~b   (and as we all know -b is (~b +1))
>
> You must mean that SBC was (A + ~B + C) = (A - B - 1 + C) = (A - B -
> borrow).  SUB has to include the 1 adjustment or else its just *wrong* :-)
>
yes, I was taking about the old 6502 (history of the Arm being the
replacement for the 6502 in acorn computers)
(still it was sbc without the sub etc etc).

SUB is A + ~b + 1; SBC A+~b+C  (RSB ~A + B + 1) etc

not Idea why anyone would consider that retarded, just different from the
Z80. (GB)
was a pain on the 6502 having to clear and set the carry flag b4 all add/sub
ops, thankfully the Arm has add/sub with carry/borrow in/out.

is there any reason to want to borrow carry, or carry borrow ?

Mappy 0.9d is the 4th release of the Mappy Virtual Machine and the first
release to be Open Source. The complete source code to both the Mappy VM
user interface and the Mappy VM core is available under the Bottled Light
Public License, similar in terms to the MPL.

The binary version of Mappy VM 0.9d is an interim release to accompany the
source code. In addition to a number of bug fixes, 0.9 is also
considerably faster than 0.8. Most of the viewers have also been improved
and the source debugger has been rewritten from scratch.

More information, binaries, and source code can be found at
http://www.bottledlight.com/mappy

On Tuesday 01 April 2003 21:17, Morten Pedersen wrote:
> you completely missed my point. i was pointing out the problem with
> operating the carry bit in this manner.

well eh :o) i just see no "problem" here at all :o) (or the point where the
behaviour is not consistent for that matter). the fact that your calculation
returns 1 is completely 100% logical and i wouldnt expect anything else.

oh well :o) useless topic to discuss anyhow.

gpz

Hello,
    I messed around with GBA development about a year ago, and I used
this thing called HAM.  Is that still around?  Is it compatible with
devkit advance and SGADE?  I'd like to do this on a mac.  Is the code I
wrote using HAM unusable?  I'm unclear as to the relationship between
these libraries/kits/whatever.

Thanks for any info!
Bob

you completely missed my point. i was pointing out the problem with
operating the carry bit in this manner.



----- Original Message -----
From: "Groepaz" <groepaz@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, April 01, 2003 3:59 AM
Subject: Re: [gbadev] Re: The carry flag


> On Monday 31 March 2003 22:15, Morten Pedersen wrote:
> > but that's completely retarded. that means (and i just tested this to be
> > true) the following code ends up with '1' in r12.
> >
> >   mov r10,#0x00000000
> >   mov r11,#0x00000000
> >   subs r12,r10,r11
> >   adc r12,r10,r11
>
> the last one should be ADD not ADC (which adds the carry => 1) :=)
>
> gpz
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> sub was infact a + ~b   (and as we all know -b is (~b +1))

You must mean that SBC was (A + ~B + C) = (A - B - 1 + C) = (A - B -
borrow).  SUB has to include the 1 adjustment or else its just *wrong* :-)

Note also that the carry *out* of this SBC operation is 1 if there was no
borrow and 0 if there is a borrow.

>   subs r12,r10,r11
>   adc r12,r10,r11

Why is this behaviour "retarded"?  I don't understand why you'd ever want to
do a SUBS followed by an ADC, except to discover which way the carry flag
was implemented.  SUBS goes with SBC/SBCS, and that obviously works just
fine.  CC and CS both exist.  I don't see the big deal here.  Is there some
cool trick that you can't do because of this, or that takes an extra cycle?

Eddie

on the 6502 it was simple to save silicon (afaik)
sub was infact a + ~b   (and as we all know -b is (~b +1)) so having the
carry as ~borrow there is no need to either invert the carry flag on sub or
negate the 2nd operand (i.e. butwise not and increment)


----- Original Message -----
From: "Morten Pedersen" <escapekey@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, March 31, 2003 9:15 PM
Subject: Re: [gbadev] Re: The carry flag


>
> but that's completely retarded. that means (and i just tested this to be
> true) the following code ends up with '1' in r12.
>
>   mov r10,#0x00000000
>   mov r11,#0x00000000
>   subs r12,r10,r11
>   adc r12,r10,r11
>
>
>
>
> ----- Original Message -----
> From: "Damian Yerrick" <d_yerrick@...>
> To: <gbadev@yahoogroups.com>
> Sent: Monday, March 31, 2003 8:28 AM
> Subject: [gbadev] Re: The carry flag
>
>
> >
> > From what I've read, the carry flag on the ARM architecture seems
> > to operate under subtraction like the one on the 6502 architecture:
> > 0 for borrow and 1 for no borrow.  The 6502 does subtraction like
> > this:
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

On Monday 31 March 2003 22:15, Morten Pedersen wrote:
> but that's completely retarded. that means (and i just tested this to be
> true) the following code ends up with '1' in r12.
>
>   mov r10,#0x00000000
>   mov r11,#0x00000000
>   subs r12,r10,r11
>   adc r12,r10,r11

the last one should be ADD not ADC (which adds the carry => 1) :=)

gpz