> How about calling BIOS SoftReset() on exit?  Would that be logical?

Anything is fine.  I try to catch myself anytime I get too worried about
calling constructors, atexit, and what to do on exit because it really isn't
an important feature.

I really just want to make it easy to override, so that things like
PogoShell or a more flexible, could handle it in whatever way they needed.
To facilitate that, I just seperated all the low level functions out into
their own object files so they can be redefined without interfering with
each other.

> In that case, I guess it'd be best to optimize libc for beta 4.

I do not want to do beta 4.  That is probably why Beta 3 is taking so long.
If I readjusted my thinking and accepted that I probably want to do a few
more beta's then I probably would have released Beta 3 already.  But, the
idea that 'beta 3 is the last beta' is forcing me to put everything I want
in the final into this next release, because it is not a good idea to add
new features to something so close to release.

I didn't want to fall into perpetual beta mode, but now I am starting to get
tired of talking about features which no one has yet.

I was hoping to have release candidate 1 after beta 3, but I think now I
probably want to go with a schedule of 1 beta release every week until it is
ready.  In that spirit, I will release what I have this weekend.

Release early, release often.

> --
> Damian

--- In gbadev@yahoogroups.com, "Jason Wilkins" <fenix@i...> wrote:
> And all I did was suggest that people take Dhrystone a little too
> seriously...

Dhrystones, meet the Dhrystones, they're a modern benchmark family!

> The default _exit() just branches to _start, but you could also
> provide your own which goes into an infinite loop or something.

How about calling BIOS SoftReset() on exit?  Would that be logical?

> It has been a month since Beta 2, so I really need to get on the
> ball!  I probably will look at this more after Beta 3, because I
> know if I get into optimizing libc, it will probably take another
> month.

In that case, I guess it'd be best to optimize libc for beta 4.

--
Damian

I bet you could write a "lex" lexical analyzer to convert between assembly
formats in about an hour.

If I had a lot of examples of ARM's assembly format, I might give it a go.

off the top of my head I would say they dont use compatible file formats

C:\temp\test>armcc -c hello.c

C:\temp\test>arm-thumb-elf-gcc -o hello.elf hello.o crt0.o -nostartfiles
c:\msys\1.0\microrad\bin\..\lib\gcc-lib\arm-thumb-elf\3.2.2\..\..\..\..\arm-thum
b-elf\bin\ld.exe: ERROR: crt0.o is compiled for EABI version 0, whereas
hello.el
f is compiled for version 2
No error: failed to merge target specific data of file crt0.o



C:\temp\test>arm-thumb-elf-gcc -c hello.c -o hello.o

C:\temp\test>armlink hello.o -o hello.elf vectors.o
Fatal error: L6007U: Could not recognize the format of file hello.o.
Finished: 0 information, 0 warning, 0 error and 1 fatal error messages.


you could compile to asm then write a program to convert one way or the
other (add colons to
labels, change DCD to .word, EXPORT to .global, etc).   Or you could write
your own
dissassembler (or borrow mine), and rip apart either of the objects to asm
that conforms with the opposite assemblers syntax.

I have been meaning to do this exact task for some time now....but have not...

Of the top of my head, for these two tools specifically the compile to asm
route might be easiest,
if you feel compelled to use Microsofts Embedded Visual C for anything you
will find the need to disassemble the object files instead of compile to asm...

Try converting the asm output from one to the other by hand a few times and
you will quickly see what needs to be done.

BTW I didnt really look to see if either provides command line switches to
alter the output...

David

At 11:20 AM 4/30/2003 +0100, you wrote:

>Hello chaps,
>
>I've a pretty large project which I'd like to selectivly optimise ( if
>possible ) using ARM ADS 1.2.
>
>One of the more complicated files gets used a lot and it would be
>interesting to see whether compiling this one under ADS makes any difference
>to the overall performance.
>
>What are the differences between the ADS and GCC object formats and is it
>possible to convert from one to the other so I can check out the compilers'
>relative efficiency without having to go through all the grief of converting
>the whole project to work with ARM ADS?
>
>Cheers,
>
>Rob.
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Hello chaps,

I've a pretty large project which I'd like to selectivly optimise ( if
possible ) using ARM ADS 1.2.

One of the more complicated files gets used a lot and it would be
interesting to see whether compiling this one under ADS makes any difference
to the overall performance.

What are the differences between the ADS and GCC object formats and is it
possible to convert from one to the other so I can check out the compilers'
relative efficiency without having to go through all the grief of converting
the whole project to work with ARM ADS?

Cheers,

Rob.

On Sun, 27 Apr 2003 23:40:05 +0000 (UTC) Justin Grimm <grimmj1@...>
wrote:
> Can anyone tell me where I can buy a flash cart for the gba?
> I can't find them at lik-sang and game gizmo aren't trading anymore.
> Alternatively is there a way to modify an existing gba cart so it
> can be programmed with the MBV2?

I recently got a F2A 256M cart from MicMic (http://www.micmic.com).
While I have some issues with their service (they explicitly told me
I'm getting a Flash Advance Pro card but shipped me a F2A card, a week
late), their price was the best. There's also Success Compu
(http://www.success-hk.com), I haven't dealt with them.

The F2A card programs fine with the MBV2 (thanks, Damian).

Regards,
Boris

> i found that one out myself when i unrolled my mixer loop code --
> surprised me, but then again, I'm not the maintainer of devkit advance
> ;)

I'm not an assembly expert, but I guess I'll become one if I keep at it.  I
didn't know much about customizing GCC before I started DevKit Advance
either ^_^

I really just need to RTFM.

It looks like I touched a nerve with David ^_^

And all I did was suggest that people take Dhrystone a little too
seriously...

I'll be happy to see what I can do with these other tests and DevKit
Advance, if only because the more code I can compile, the more bugs I can
find.  Also, code that really works out libc allows me to trim fat.

For example, in order to be ANSI C compliant, AgbMain (which is called by
crt0.S) looks something like this:

atexit(_fini); // destructor function '_fini' will be called last by exit
_init(); // constructors
exit(main(0,0,0)); // call exit with return value of main.  it does atexit
stuff then calls _exit

I noticed that atexit uses malloc by default, so every program with C++
support would require it (all 3k of it).  But, I managed to remove that
dependency.  The default _exit() just branches to _start, but you could also
provide your own which goes into an infinite loop or something.

It has been a month since Beta 2, so I really need to get on the ball!  I
probably will look at this more after Beta 3, because I know if I get into
optimizing libc, it will probably take another month.

Everything is pretty much lined up, I just wanted to write some docs and
examples before unleashing it.

Here is the data you wanted to see....

bzip (libbzip2) on the gba, wouldnt do much more than 3000 bytes without
crashing somewhere (most likely out of memory or stack or something like
that, who knows, I am really tired of messing with it).

gcc 3.2.2 vs ARM (thumb mode, tcc) ADS 1.2.
compressed 1000 bytes, then 2000 bytes, then 3000 bytes.  It was
interesting what gcc was doing at first as it lost to arm at the 1000 byte
level but not at the 3000 byte level.  The code at the time looked
something like this:

	 time1=READTIMER();
	 time2=INTCOUNT;
	 time3=READTIMER();
	 ..stuff...
	 printf("TIME %lu %lu %lu\n",time1,time2,time3);

Turns out ADS would read time1, 2, and 3 when and where I told it to, gcc
would basically wait until the printf needed time1, and time3 at least and
would read them then, you could get dramatically different results with gcc
by moving things around, eventually I ended up with
	 time1=READTIMER();
	 printf("TIME %lu\n",time1);
	 ...stuff...

And gcc wins across the board...

ARM ADS (Thumb) v1.2  build 842    tcc -Otime -c prog.c
1000  8756
2000  16285
3000  19260
3000pre 11320 (waitcnt set to 3/1 and prefetch buffer enabled)

GCC 3.2.2 (my build)    gcc -O3 -mthumb -c prog.c -o prog.o
1000  7169
2000  13507
3000  16744
3000pre 9677

I am curious to see devkitadv match my numbers.

All files are available on the net:
http://www.dwelch.com/gba/bzipgcc000.zip
http://www.dwelch.com/gba/bziparm000.zip
http://www.dwelch.com/gba/bziparmlst000.zip  (in case you want to see the
arm listing)...

I downloaded bzip last night so its a fresh version (1.02 I think).  To get
it to work with ADS took some work, had to define BZ_NO_STDIO or something
and change fprintf(stderr, to printf( in a number of places.  Anyway the
both sources are there, I tried hard to keep them as equal as I could,
hopefully I pulled that off...

David

--- In gbadev@yahoogroups.com, "Daniel" <webmaster@i...> wrote:
> I have tried to write my flash cart with the MBV2 cable.
>
> Does anyone know how to erase and program flash from the GBA?

The flash cart code in mb.exe can only write to Visoly compatible
carts such as Flash2Advance.  It probably won't work with XG-Flash,
Xport, or homemade flash.  If you're building your own flash cart,
you'll have to write your own GBA-side code using mbv2lib, which
you can download at devrs.com.

--
Damian

Okay, I am trying to understand flash programming on the gba.  Looking at
an intel data sheet it basically says write 0x90 to any address then read
from an address with A0 = 0 and A0 = 1

so if r0 = 0x8000000 and r1=0x90 then shouldnt something like this work:

      strh r1,[r0]
      ldrh r1,[r0]
   ( mov r0,r1; bx lr)

But I only get the bytes that were programmed into the cart by the MBV2 the
last time I programmed it...strb/ldrb doesnt help.

David

I had a few warnings, nothing major, most of them were in the bzip code
related to :

          if(something)
                  myfun(something);

which is called an empty body if statement or something...

          if(something)
          {
                  myfun(something);
          }

This gets rid of those warnings, the others were unused parameters in a
function:


          int something ( int a, int b)
          {
                  return(b+1);
          }

a is unused...



It looks like memory is getting corrupt, the program is getting overwritten...

(its not obvious, the cpsr is 0xdb, r14_und is 0x84b4c so the undefined
instruction is at
0x84b4a, which is supposed to be 0x2197 but has been corrupted to 0xE922
which is truly undefined 11101xxxxxxxxxxxb )

  >> loadelf "test.elf"
00000000 000000BC (188) WRITING
00000000 000000BC (188) READING
00080000 0000FE24 (65060) WRITING
00080000 0000FE24 (65060) READING
  >> write register 15 0
  >> restart
  > read register 0
    0x00084b4c
  > read register 1
    0x00000000
  > read register 2
    0x000000db
  > read register 3
    0x000000f3
  > read register 4
    0x03000264
  > read memory 0x84b40 100
00084b40:  0x30016820  0xf7fe6020  0xe92298fd  0x18f2008b
00084b50:  0x28076810  0x2096dd12  0x19300084  0x6cf21c14
00084b60:  0x78c36af1  0x6cf1548b  0x31016802  0x021164f1
00084b70:  0x3a086822  0x60226001  0xdcf02a07  0x68144672
00084b80:  0x60143401  0xfc84f7fe  0xf7fb483b  0xf7fefc01
00084b90:  0x483afc19  0xfbfcf7fb  0xfc10f7fe  0xf7fb4838
00084ba0:  0xf7fefbf7
  >

     84b40:       6820            ldr     r0, [r4, #0]
     84b42:       3001            add     r0, #1
     84b44:       6020            str     r0, [r4, #0]
     84b46:       fce9f7fe        bl      8351c <sendMTFValues+0xdb0>
     84b4a:       2197            mov     r1, #151
     84b4c:       008b            lsl     r3, r1, #2
     84b4e:       18f2            add     r2, r6, r3
     84b50:       6810            ldr     r0, [r2, #0]
     84b52:       2807            cmp     r0, #7
     84b54:       dd12            ble     84b7c <sendMTFValues+0x2410>
     84b56:       2096            mov     r0, #150
     84b58:       0084            lsl     r4, r0, #2
     84b5a:       1930            add     r0, r6, r4
     84b5c:       1c14            mov     r4, r2          (add r4, r2, #0)







At 11:51 PM 4/28/2003 +0000, you wrote:
>--- In gbadev@yahoogroups.com, David Welch <gba@d...> wrote:
> >
> > Thumb mode with ADS takes the binary even smaller, gcc gets
> > a good shrink too, unfortunately it wouldnt run for me (no
> > compiler errors or warnings)
>
>Are you sure you used -Wall -W?
>
> > Unfortunately I had time stamps that included printfs
>[...]
> > a while ago I stopped trying to trim the fat out of the binary,
> > there could very well be 20k of c library junk in there
>
>It's printf().  If you use printf() on an target with static
>linking and without an FPU, then printf() has to pull in
>the whole floating point math library.  To avoid this, use
>newlib's iprintf(), which is the same as printf() except that
>iprintf() does not handle floating point.
>http://www.objsw.com/docs/libc_65.html
>
>--
>Damian
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Monday, April 28, 2003, at 12:12 PM, Jason Wilkins wrote:
> Thanks to your code, I learned the .rept/.endr pseuo opt.  ^_^  Thank
> you!

lol --

i found that one out myself when i unrolled my mixer loop code --
surprised me, but then again, I'm not the maintainer of devkit advance
;)

On Sunday, April 27, 2003, at 04:58 PM, joni_huhmarniemi wrote:
> Maybe I'll still try that one, althought I suck in asm... :/

wow -- you're pretty brave, aren't you?  you're writing 3d graphics
code for a 16mhz cpu, and you're put off by asm... now, granted, not
everyone needs/should use assembler, but this code sounds like a good
reason to learn.  I recommend just biting the bullet, and sitting down
with a book like ARM System-on-chip Architecture (ISBN 0-201-67519-6)
and learning what you can.  ARM assembly code is actually pretty easy
to get a grasp on.  Writing good assembly code is tougher, but once you
get over the hurdle of getting started, you can work on making it
better :)

dennis

How do you write to the flash cart from the GBA?  I have tried to write my
flash cart with the MBV2 cable.  Just incase it was just my flash cart, I
tried a Xport cart.  Same thing.. 'No flash cart installed'

Does anyone know how to erase and program flash from the GBA?

-Thanks,
     Daniel

Ok. My flash carts have passed the beta stage.  The next question I have is
this:  Will the newer BM software program any flash?

--- In gbadev@yahoogroups.com, David Welch <gba@d...> wrote:
>
> Thumb mode with ADS takes the binary even smaller, gcc gets
> a good shrink too, unfortunately it wouldnt run for me (no
> compiler errors or warnings)

Are you sure you used -Wall -W?

> Unfortunately I had time stamps that included printfs
[...]
> a while ago I stopped trying to trim the fat out of the binary,
> there could very well be 20k of c library junk in there

It's printf().  If you use printf() on an target with static
linking and without an FPU, then printf() has to pull in
the whole floating point math library.  To avoid this, use
newlib's iprintf(), which is the same as printf() except that
iprintf() does not handle floating point.
http://www.objsw.com/docs/libc_65.html

--
Damian

Hmmm, I am probably the leader of the ARM is better than gcc by 30% nya,
nya, nya campaign and will try to stop that.  Here are some numbers to show
data in the other direction, I know I tried to do these tests on a gba but
there is just so little memory I either gave up or the data sample was too
small to get a good comparison...

On a non-gba ARM platform with a 32bit data bus, cache off, write buffer
off.  This
test takes 64kbytes of text, uses the bzip compression routine, then
decompresses it.
The first time stamp is just before compression starts (boot, init,
printfs, etc)
The second time stamp is just after (and the second column is the difference
between time2 and time1).
The third time stamp is after decompression then the difference between
time3 and time2 (the decompress time) and the difference
between time3 and time1 (total compress/decompress time).

Dont try to compare 17197 with 21861, its apples and oranges,
look at 742780 vs 848020 and 269617 vs 312543 and
1012397 vs 1160563...


-- gcc 3.2.2 arm mode --
      -O3

SECTION 00000000 00000070 00000070 (112)
SECTION 00080000 00016224 00016904 (92420)

TIME 17197
TIME 759977 742780
TIME 1029594 269617 1012397


-- ARM C Compiler, ADS1.2 [Build 842] --
      -Otime

SECTION 00000000 0000002C 0000002C (44)
SECTION 0007FF00 00000010 00000010 (16)
SECTION 00080000 0000B310 0000B3AC (45996)

TIME 21861
TIME 869881 848020
TIME 1182424 312543 1160563

Thumb C Compiler, ADS1.2 [Build 842]
      -Otime

SECTION 00000000 0000002C 0000002C (44)
SECTION 0007FF00 00000010 00000010 (16)
SECTION 00080000 000084B8 00008554 (34132)

TIME 18038
TIME 1048256 1030218
TIME 1479433 431177 1461395

gcc 3.2.2 thumb mode
      -O3 -mthumb

SECTION 00000000 000000BC 000000BC (188)
SECTION 00080000 0000F84C 0000FF24 (65316)

Failed to complete, I got an undefined exception trap, its
not obvious why at this point...


So for arm mode gcc is almost 15% faster but at the same time
gcc's binary is twice the size of arms.   Thumb mode with ADS takes
the binary even smaller, gcc gets a good shrink too, unfortunately it
wouldnt run for me (no compiler errors or warnings), nevertheless you can
get a feel for the size numbers and percentages between arm/thumb modes
within the same compiler...

I took some old numbers from the same platform using ads 1.2 and gcc 3.1.1
arm mode only.  Unfortunately I had time stamps that included printfs and
init and things like that so I would say the numbers are not exactly apples and
apples.  This test used the zlib library (gzip) on the same data.  For the
decompress
section arm was 11% faster but overall boot to finish  gcc was 30%
faster.  Although
gcc's binary was 78% larger.  (77760 bytes compared to 43616)

Both of these were home built gcc cross compilers not devkitadv, a while
ago I stopped trying to trim the fat out of the binary, there could very
well be 20k of c library junk in there or whatever Jason found the other
day making the gcc size numbers look so bad.  As far as the data goes I
pulled 64K bytes out of a Mark Twain book that I got from the gutenburg
project, so I would call it real world, it compressed the 64k down to a
little over 20K.  At one point in time I ran these zlib and gzip tests with
random data (does not compress, in fact it blows up bigger than it
started) and it takes longer, in theory.

And yes, I have seen test programs (other than benchmarks like dhrystone)
that have arm ads beating gcc by quite a bit...

David

Dhrystone info:

http://www.arm.com/support/588MRV/$File/Dhrystone+White+Paper.PDF
http://www.ebenchmarks.com/download/ECLDhrystoneWhitePaper2.pdf

http://www.eembc.org
http://www.specbench.org




At 12:28 PM 4/28/2003 -0600, you wrote:

>You are exactly right, a benchmark is just a benchmark.  and the Dhrystone
>is a well know one.  My page is just a comparison of dhrystone runs for the
>most part.  And I hope that everyone understands the value of a benchmark,
>both its pros and cons.
>
>Many take benchmarks as seriously as religion and as violently.  For some
>time I have wanted to use something other than dhrystone to compare
>compilers, part of the problem is...well...what code should I use?  Same
>benchmark problem.  I have recently used open source libraries like jpeg,
>jpeg2000, zlib, bzip, mad (mp3 audio decoder), to both test a system and
>where possible to benchmark.  Whats really nice about gcc is how simple it
>is to fake out a file system with memory, all the magic is in
>syscalls.c.  For the ARM compiler it is certainly possible and I have done
>a few if not all of the above and more, some of those libraries/sources you
>will find, to make the programmers job easier, ask for a file pointer and
>just attack the file rather than give an option to give a pointer to a
>block of memory.  Mallocs are also an issue.  So again, you can do all of
>this with ADS (usually, although I gave up on frotz) the problem with ADS
>is that IF you supply a low level read or write function it will faithfully
>try to use your open or close or read or write, but at the same time there
>might be an fflush or ftell or something you didnt see in the code and it
>will pull in its own library and then the linker will complain about the
>conflict.  So how do you know you have a ftell or fflush problem when it
>complains that open, close, read, write, seek, etc are all duplicated (and
>never mentions ftell and fflush)?  Its a painfully iterative process, sure
>you could dig through their source code but that still might not get you to
>the end, sometimes I link without my code then wade through the disassembly
>looking for key words like seek or write or whatever, also the linker pulls
>in that stdio library into one place so you might see a seek right next to
>the write or read.  Its still quite painful compared to gcc.
>
>Hmmm, I am turning this into a long story, I cant remember which things I
>actually got running on the gba (jpeg, zlib, bzip, jpeg2000, etc).  Pretty
>much all of the time I run into a lack of memory problem, (and it doesnt
>help that the programs run great on the emulator but not on the hardware).
>Even converting the tiniest image from one format to jpeg or jpeg to
>something else chews up a lot of memory due to mallocs, the cases that I
>might have actually gotten something to run it might have been as lame as
>trying to compress 100 bytes to 75 bytes and how useful of a benchmark is
>that?
>
>Back to the dhrystone.  If nothing else you can see changes within the same
>compiler.  For example gcc 3.2.3 came out last week, I got the same score
>as 3.2.2 (didnt check byte for byte or size differences) so I didnt mention
>it...There was a noticable difference between 2.95.3 and 3.0, and there
>have been small improvements between 3.0, 3.1, and 3.2, so I would argue
>the dhrystone is useful there.  Also comparing arm performance to thumb
>performance from the same vendor, that or the ratio of arm performance to
>thumb performance.
>Also the dhrystone does exercise a number of things that might trip up a
>compiler.  But there is a huge opportunity to cheat and make your compiler
>do well for the popular benchmarks but not necessarily for general purpose.
>
>I have put gcc head to head with ADS in some real world situations and ADS
>still wins, not sure if its 30% or not, I will try to find some of those
>numbers (non-GBA)...
>
>Really the bottom line, which I have also wanted to spell out on some web
>page somewhere is that each compiler has its pros and cons, take for
>example the stdio stuff between gcc and ARM.  Green Hills was the easiest
>to get running in a rommable form (no Angel calls or anything like
>that).   Just take the compiler out of the box, install, compile a hello
>world, figure out where the entry code is and how to initialize the system
>and call main, etc.  GHS was easiest (the last time I tried it a year or
>two ago), Metaware was second. gcc third, and ARM was by far the hardest
>the first time, but their examples got better and eventually helped quite a
>bit.  malloc is also a good topic for comparison, some compilers are tough
>some are easy when it comes to malloc.
>
>I was reading about the whetstone recently (have used it as well for
>testing compilers and an fpu).
>Supposedly it "does nothing" and a really good compiler might figure that
>out.  I think it was a head to head with gcc vs Intels compiler, and Intels
>figured out the code did nothing and just cut it out, ran damn fast I would
>assume.  So even if you dont try to cheat to win a particular benchmark,
>your optimizer may be so good that it has side effects that help you win,
>this intel case above, and for example the queens problem/benchmark.
>
>I like what the SPEC folks have done, take a collection of real world
>applications and put them head to head, problem is I didnt want to fork out
>the money to buy their tests and most of the sources are no longer
>available on the net...
>
>
>
>Two conclusons to all of this benchmarking and compiler comparisons, etc I
>have done.
>
>1) Try them all yourself, ARM, GHS, Metware all have eval versions, just
>try them....just do it!  GCC, take a stab at building it yourself, learn to
>control both crt0.s and the linker as well as understand how much power you
>have in syscalls.c (newlib).   Certainly not to turn you off of
>devkitadv, but more to understand what your compiler can do for you...In
>the same way that a Computer Scientist might know that a particular problem
>might be solved best with java over C or C++, you as a programmer might
>know that this source I found/need will build better with this compiler and
>not at all with that compiler, you could spend $10,000 trying to get gcc to
>do something that ADS might do quite well (at $4000)...
>
>
>2) The gba has been hobbled by N.  Its so sad, either more mhz or a little
>tiny cache or zero wait state memory busses.  Things that IMO would cost
>only a few bucks at most to the end user, could have made the difference
>between a good platform for games or a platform only good enough for tile
>based sliders...I have not found the quote in print (not really looked) but
>in my dealings with ARM, supposedly the ARM7 can get over 90% mips to mhz,
>so using their own compiler on a roughly 16mhz platform that would be at
>least 14 mips.  Well you can see, how far off we are from that with slow,
>16 bit busses and no cache, its just sad...
>
>
>blah, blah, blah, sorry for the narrative.  ITS JUST A BENCHMARK.  If you
>use ADS learn how to disassemble with fromelf, if you use gcc objdump -D
>myprog.elf > myprog.lst.   Just look at the asm produced by any particular
>function, watch how the asm changes when you do certain things (lean
>towards global vs local variables, increase/reduce the number of arguments
>in a function call, etc).  One big mistake would be to heavily tune your C
>code to produce better asm, that will bite you in the end, dont do it (in
>general).  It would be better to go from C to asm once, then steal the asm
>and just use it as asm from then on.  I have found that the compiler,
>particularly ARM but sometimes GCC, generates code sequences that are much
>better than ones I would come up with  on my own had I written the asm from
>scratch (mostly its that I dont remember every quirk of every instruction
>at every moment, but instead think in terms of a generic processor then
>write the asm for a specific one).  But at the same time, you can look at
>code generated and wonder why did you switch registers there or if you did
>it this way you could have saved three instructions, etc, etc.
>
>Performance is an art form...
>
>David
>
>
>
>At 11:02 AM 4/28/2003 -0500, you wrote:
> >If you haven't, I think it would be great if you posted this white paper
> >by ARM on your benchmark page.
> >
> >http://www.arm.com/support/588MRV/$File/Dhrystone+White+Paper.PDF
> >
> >I think that people take your Dhrystone numbers way too seriously.  People
> >talk about "30 percent" differences between GCC and ADS, and it all comes
> >from your benchmark numbers I think.
> >
> >In the real world, I think that the compilers are actually much closer.
> >I've never witnessed gcc do anything horribly bad.  30 percent would not
> >be hard to spot, I think it would show up even in the relatively simple
> >code which I am constantly reading from the compiler.  I do admit that
> >I've never had the patience to read really complicated code, but in most
> >cases I have seen it produce exact the same code I would write myself (not
> >that I'm that great).
> >
> >I'm not trying to criticize you.  I think your numbers show a real
> >difference between compilers.  I also think they are great demonstrations
> >of the difference in speed between the different memory regions and
> >settings.  I also really think that the ARM code generation in GCC needs
> >to be improved (reading the changlog, I see no updates to it in several
> >releases).
> >
> >I guess it is a matter of degree.
> >
> >I'm trying not to sound like some marketing goon or evangelist who is
> >unhappy with how their product is being presented by the press ^_^
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

You are exactly right, a benchmark is just a benchmark.  and the Dhrystone
is a well know one.  My page is just a comparison of dhrystone runs for the
most part.  And I hope that everyone understands the value of a benchmark,
both its pros and cons.

Many take benchmarks as seriously as religion and as violently.  For some
time I have wanted to use something other than dhrystone to compare
compilers, part of the problem is...well...what code should I use?  Same
benchmark problem.  I have recently used open source libraries like jpeg,
jpeg2000, zlib, bzip, mad (mp3 audio decoder), to both test a system and
where possible to benchmark.  Whats really nice about gcc is how simple it
is to fake out a file system with memory, all the magic is in
syscalls.c.  For the ARM compiler it is certainly possible and I have done
a few if not all of the above and more, some of those libraries/sources you
will find, to make the programmers job easier, ask for a file pointer and
just attack the file rather than give an option to give a pointer to a
block of memory.  Mallocs are also an issue.  So again, you can do all of
this with ADS (usually, although I gave up on frotz) the problem with ADS
is that IF you supply a low level read or write function it will faithfully
try to use your open or close or read or write, but at the same time there
might be an fflush or ftell or something you didnt see in the code and it
will pull in its own library and then the linker will complain about the
conflict.  So how do you know you have a ftell or fflush problem when it
complains that open, close, read, write, seek, etc are all duplicated (and
never mentions ftell and fflush)?  Its a painfully iterative process, sure
you could dig through their source code but that still might not get you to
the end, sometimes I link without my code then wade through the disassembly
looking for key words like seek or write or whatever, also the linker pulls
in that stdio library into one place so you might see a seek right next to
the write or read.  Its still quite painful compared to gcc.

Hmmm, I am turning this into a long story, I cant remember which things I
actually got running on the gba (jpeg, zlib, bzip, jpeg2000, etc).  Pretty
much all of the time I run into a lack of memory problem, (and it doesnt
help that the programs run great on the emulator but not on the hardware).
Even converting the tiniest image from one format to jpeg or jpeg to
something else chews up a lot of memory due to mallocs, the cases that I
might have actually gotten something to run it might have been as lame as
trying to compress 100 bytes to 75 bytes and how useful of a benchmark is that?

Back to the dhrystone.  If nothing else you can see changes within the same
compiler.  For example gcc 3.2.3 came out last week, I got the same score
as 3.2.2 (didnt check byte for byte or size differences) so I didnt mention
it...There was a noticable difference between 2.95.3 and 3.0, and there
have been small improvements between 3.0, 3.1, and 3.2, so I would argue
the dhrystone is useful there.  Also comparing arm performance to thumb
performance from the same vendor, that or the ratio of arm performance to
thumb performance.
Also the dhrystone does exercise a number of things that might trip up a
compiler.  But there is a huge opportunity to cheat and make your compiler
do well for the popular benchmarks but not necessarily for general purpose.

I have put gcc head to head with ADS in some real world situations and ADS
still wins, not sure if its 30% or not, I will try to find some of those
numbers (non-GBA)...

Really the bottom line, which I have also wanted to spell out on some web
page somewhere is that each compiler has its pros and cons, take for
example the stdio stuff between gcc and ARM.  Green Hills was the easiest
to get running in a rommable form (no Angel calls or anything like
that).   Just take the compiler out of the box, install, compile a hello
world, figure out where the entry code is and how to initialize the system
and call main, etc.  GHS was easiest (the last time I tried it a year or
two ago), Metaware was second. gcc third, and ARM was by far the hardest
the first time, but their examples got better and eventually helped quite a
bit.  malloc is also a good topic for comparison, some compilers are tough
some are easy when it comes to malloc.

I was reading about the whetstone recently (have used it as well for
testing compilers and an fpu).
Supposedly it "does nothing" and a really good compiler might figure that
out.  I think it was a head to head with gcc vs Intels compiler, and Intels
figured out the code did nothing and just cut it out, ran damn fast I would
assume.  So even if you dont try to cheat to win a particular benchmark,
your optimizer may be so good that it has side effects that help you win,
this intel case above, and for example the queens problem/benchmark.

I like what the SPEC folks have done, take a collection of real world
applications and put them head to head, problem is I didnt want to fork out
the money to buy their tests and most of the sources are no longer
available on the net...



Two conclusons to all of this benchmarking and compiler comparisons, etc I
have done.

1) Try them all yourself, ARM, GHS, Metware all have eval versions, just
try them....just do it!  GCC, take a stab at building it yourself, learn to
control both crt0.s and the linker as well as understand how much power you
have in syscalls.c (newlib).   Certainly not to turn you off of
devkitadv, but more to understand what your compiler can do for you...In
the same way that a Computer Scientist might know that a particular problem
might be solved best with java over C or C++, you as a programmer might
know that this source I found/need will build better with this compiler and
not at all with that compiler, you could spend $10,000 trying to get gcc to
do something that ADS might do quite well (at $4000)...


2) The gba has been hobbled by N.  Its so sad, either more mhz or a little
tiny cache or zero wait state memory busses.  Things that IMO would cost
only a few bucks at most to the end user, could have made the difference
between a good platform for games or a platform only good enough for tile
based sliders...I have not found the quote in print (not really looked) but
in my dealings with ARM, supposedly the ARM7 can get over 90% mips to mhz,
so using their own compiler on a roughly 16mhz platform that would be at
least 14 mips.  Well you can see, how far off we are from that with slow,
16 bit busses and no cache, its just sad...


blah, blah, blah, sorry for the narrative.  ITS JUST A BENCHMARK.  If you
use ADS learn how to disassemble with fromelf, if you use gcc objdump -D
myprog.elf > myprog.lst.   Just look at the asm produced by any particular
function, watch how the asm changes when you do certain things (lean
towards global vs local variables, increase/reduce the number of arguments
in a function call, etc).  One big mistake would be to heavily tune your C
code to produce better asm, that will bite you in the end, dont do it (in
general).  It would be better to go from C to asm once, then steal the asm
and just use it as asm from then on.  I have found that the compiler,
particularly ARM but sometimes GCC, generates code sequences that are much
better than ones I would come up with  on my own had I written the asm from
scratch (mostly its that I dont remember every quirk of every instruction
at every moment, but instead think in terms of a generic processor then
write the asm for a specific one).  But at the same time, you can look at
code generated and wonder why did you switch registers there or if you did
it this way you could have saved three instructions, etc, etc.

Performance is an art form...

David



At 11:02 AM 4/28/2003 -0500, you wrote:
>If you haven't, I think it would be great if you posted this white paper
>by ARM on your benchmark page.
>
>http://www.arm.com/support/588MRV/$File/Dhrystone+White+Paper.PDF
>
>I think that people take your Dhrystone numbers way too seriously.  People
>talk about "30 percent" differences between GCC and ADS, and it all comes
>from your benchmark numbers I think.
>
>In the real world, I think that the compilers are actually much closer.
>I've never witnessed gcc do anything horribly bad.  30 percent would not
>be hard to spot, I think it would show up even in the relatively simple
>code which I am constantly reading from the compiler.  I do admit that
>I've never had the patience to read really complicated code, but in most
>cases I have seen it produce exact the same code I would write myself (not
>that I'm that great).
>
>I'm not trying to criticize you.  I think your numbers show a real
>difference between compilers.  I also think they are great demonstrations
>of the difference in speed between the different memory regions and
>settings.  I also really think that the ARM code generation in GCC needs
>to be improved (reading the changlog, I see no updates to it in several
>releases).
>
>I guess it is a matter of degree.
>
>I'm trying not to sound like some marketing goon or evangelist who is
>unhappy with how their product is being presented by the press ^_^

--- In gbadev@yahoogroups.com, "Joni Huhmarniemi"
<joni.huhmarniemi@s...> wrote:
> > Swings and round-a-bouts.
> >
> > You have to ask yourself the question: Is it more expensive to
render over
> > some areas of the screen multiple times and use a bucket sort
buffer with
> my
> > texture mapped polygons; or do I save time by sorting the
polygons in to a
> > span-buffer and only drawing things once?
>
>
> Good question, of course. But my case, which was a vector
> graphics engine, is a bit different from filled / textured polygons!
> There's not so much overlapping pixels, really.

I've contemplated writing a vector graphics engine myself for the
Palm... have you considered drawing over the previous frame's
graphics with the clear color? Up to a point, this ought to be faster
than filling the entire framebuffer. And you can probably find that
point (total # of vectors > N? total drawn pixels > N? render time >
N tics?), empirically or otherwise, and switch to a full framebuffer
clear if you go beyond it on a given frame.

Hopefully the break-even point doesn't reside at two or three
vectors ;)

Darren

On Mon, 28 Apr 2003, Pete wrote:

> http://bits.bris.ac.uk/dooby/gba/clsUnroll.txt

Thanks to your code, I learned the .rept/.endr pseuo opt.  ^_^  Thank you!

> Cheers, Pete
> --
> http://www.bits.bris.ac.uk/dooby/
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

On Sun, 27 Apr 2003, Joni Huhmarniemi wrote:

> I'm in my early steps in GBA development, and I've chosen to
> learn the environment by writing a simple vector gfx engine for
> mode 4. I'm almost done, but my lame implementation for
> filling the back buffer gives me a headache! (code below)
>
> Profiling tells that my routine takes almost one tenth of ticks in
> a single frame! This is obiviously no good. I've experimented
> with basic memset functions etc., but this is the fastest way I've
> found so far:

I found that unrolling a STore Multiple loop which pushed 14 registers of
colour at a time was fastest for me. It does cost in size - I think 2836
bytes (8.7%) of IWRAM but for Mode 4 I reckoned it was taking 19,971
cycles - about 16 scanlines or 7% of a 60Hz frame.

All this is from quite a while back so if I've mis-calculated something
please let me know. The reason it's faster than DMA from IWRAM is
(AIUI) that the STMs don't have the overhead of reloading the source.

The code's in my gbalib.zip, from the GBA section on my website (see
sig) but I uploaded just the clearscreen routine to

http://bits.bris.ac.uk/dooby/gba/clsUnroll.txt

Cheers, Pete
--
http://www.bits.bris.ac.uk/dooby/

On Mon, 28 Apr 2003, Joni Huhmarniemi wrote:
> Has anyone done speed comparisons between BIOS CPUFastSet
> and DMA transfers? I failed to implement the necessary asm to try
> that by my self... :(


I wrote a line filler in iwram which looked like this:

str r0! [r1]
str r0! [r1]
str r0! [r1]
str r0! [r1]
str r0! [r1]
str r0! [r1]
str r0! [r1]
...

120 times.

It was able to clear the screen about 200 times a second.  At 60 FPS, that
would be 3/10ths of each frame.  It was mode 3, so that was like 7
megapixels per second.  If it was mode 4, I guess it would be 400 times a
second, and be 3/20th of each frame.

There was a little bit of overhead at the beginning for writing the
beginning an end of the line if it was odd, as well as loop overhead of
doing it 160 times, but I doubt it was more than 1 percent.

It is clear that if he is clearing mode 4, and it takes 1/10th of a frame
then DMA is faster (and if mode 3, then it's way faster).  My problem with
DMA is that it has a lot of overhead to setup.  I wonder how it would
behave for filling flat polygons when those polygons are small.  Anyone
have some insight?

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

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

From: "Joni Huhmarniemi" <joni.huhmarniemi@...>

> Has anyone done speed comparisons between BIOS CPUFastSet
> and DMA transfers? I failed to implement the necessary asm to try
> that by my self... :(

CpuSet is slow.  there is only one case where CpuFastSet is faster than
using DMA: if you're using CpuFastClear, which takes advantage of the ARM's
multiple load/store instructions.

DmaClear reloads a fixed source address on every transfer.

regards,
matthew.

> Swings and round-a-bouts.
>
> You have to ask yourself the question: Is it more expensive to render over
> some areas of the screen multiple times and use a bucket sort buffer with
my
> texture mapped polygons; or do I save time by sorting the polygons in to a
> span-buffer and only drawing things once?


Good question, of course. But my case, which was a vector
graphics engine, is a bit different from filled / textured polygons!
There's not so much overlapping pixels, really.

Has anyone done speed comparisons between BIOS CPUFastSet
and DMA transfers? I failed to implement the necessary asm to try
that by my self... :(

--joni

Thanks everyone, so the flash2advance is all I need to program a flash rom from
my pc?

Thanks
Justin
   ----- Original Message -----
   From: Daniel
   To: gbadev@yahoogroups.com
   Sent: Monday, April 28, 2003 2:00 PM
   Subject: Re: [gbadev] Flash carts


   I would like to say I use these and they work great.  The also program a LOT
   faster than my xport..
   ----- Original Message ----- > Does a whole lot more than just act as a
   flash cart but
   > http://www.charmedlabs.com
   > has a product with 32mbits of flash...




         Yahoo! Groups Sponsor



   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Swings and round-a-bouts.

You have to ask yourself the question: Is it more expensive to render over
some areas of the screen multiple times and use a bucket sort buffer with my
texture mapped polygons; or do I save time by sorting the polygons in to a
span-buffer and only drawing things once?

-----Original Message-----
From: joni_huhmarniemi [mailto:joni.huhmarniemi@...]
Sent: 28 April 2003 11:42
To: gbadev@yahoogroups.com
Subject: [gbadev] Re: Fastest way to fill the back buffer?



> best way would be to use span-buffers. that way you only draw each
pixel
> once and don't actually need to clear the back-buffer as such :)
>
> ninge

Whoa, brave approach! :) That's very memory intensive, isn't it?

--Paolo







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

Hi,

We've recently ordered the GBA Tranverter from Lik-Sang.com.

It only costs about 30 euros and works like a charm. Only one drawback is
that is sometimes 'loses' pixels when things move too fast, but nothing
really worrying.

Bye,

Collin
----- Original Message -----
From: "CK" <x@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, April 28, 2003 12:01 PM
Subject: [gbadev] tv out


> hi,
>
> last week my gameboys were stolen on a train and now I need a quick way
> to get a gba tv out adaptor but the guys over at cdworld.co.uk don't
> seem to sell them any more.
> Does any one of you know of a source ? Some company that is esp. fast in
> shipping to europe would be even better ...
>
> thanks in advance,
>
> x
>
> --
> chris@... Postmodernism is german romanticism with better
> http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

How about a GB player for the GC?

-----Original Message-----
From: CK [mailto:x@...]
Sent: 28 April 2003 11:02
To: gbadev@yahoogroups.com
Subject: [gbadev] tv out


hi,

last week my gameboys were stolen on a train and now I need a quick way
to get a gba tv out adaptor but the guys over at cdworld.co.uk don't
seem to sell them any more.
Does any one of you know of a source ? Some company that is esp. fast in
shipping to europe would be even better ...

thanks in advance,

x

--
chris@... Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)





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

> best way would be to use span-buffers. that way you only draw each
pixel
> once and don't actually need to clear the back-buffer as such :)
>
> ninge

Whoa, brave approach! :) That's very memory intensive, isn't it?

--Paolo