On Fri, 9 Apr 1999, Tom Zerucha wrote:
> On Thu, 8 Apr 1999, Tom Zerucha wrote:
>
> > With -Oanything
> >
> > Graphics.s :
> >
> > move.l (%a2),%d0
> > jbeq .L10
> > clr.b -(%sp)
> > move.l %d0,-(%sp)
> > trap #15; dc.w 0xa1f8
> > .L10:
> >
> > Note the missing "addq.w #6,%sp".
>
> But this would be taken care of by the unlk instruction following.
>
> I think there is something strange within WinDeleteWindow that is causing
> the hang - WinRemove generates almost identical code and doesn't crash.
>
> If GCC was writing bad code for one, it would write bad code for the
> other.
no more problems.
the code for the Win* routines do not even exist in any of
the compilers (regardless if they say they do) - thats why
i could not fine the source code. :))
the Palm interface is smart (IMHO) - what they have done is
essentially setup a series of callbacks for all of the
PalmOS routines..
this is exactly what happens with interrupt tables for those
who program back in the old MSDOS days. i looked frantically
through the header files and figure this one out.
all routines are performed using system traps, which are
stored starting at address at 0xA000. this of course, ensures
that regardless of what development environment you are using,
the code will still operate in the same manner (as the routines
are in ROM).
using gcc, CW, or whatever... it all works out to be the same
underlying code.
the compiler you use must simply be able to translate the
calls to these system traps. (which can be done in C using
enumerated types)
check out <System/SysTraps.h> for this.
the preference of compiler depends solely on how you want
to write your code (using UI stuff, or like me, Makefile's
and command line interaction).
of course there are times when the generation of some
'asm' code is buggy - but this is not so often..
the error i posted before was my own.. not any compiler.
and now that i have found that out - and how the PalmOS
works, i am going to stick to gcc..
why?
free.. why pay so much money for a program that performs
nothing - except being able to translate C code into
m68k assembler, and translate any routines to system
traps?
hmm.. how hard could it be to code this?
---
move.w %d4,-(%sp)
move.w %d5,-(%sp)
move.w %d6,-(%sp)
move.w %d7,-(%sp)
trap #15; dc.w 0xa214
---
that is the asm source for one of the routines for
drawing a line. the routine at 0xa214 is the routine
defined as:
WinDrawGrayLine(x1,y1,x2,y2)
gcc has a reliable optimizer.. every damn unix system
has been compiled with it.. it must work fine..
if you are wondering about the effectiveness of what
environment you wish to work in - just make sure you
cover all the conditions.
free is not always bad...
if you choose gcc, and with all the free utilities
that come with it - you can do just as much as you
can with CodeWarrior. if anything - i even think you
can get better code from gcc.
the m68k cross compiler in gcc has been around longer
than CodeWarrior..
i had my doubts about gcc until i sat down and performed
a little bit of RTFM.. (and looking at the code).. it
pays to do this first.
cheers.
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 352 8192 A/H: +46 26 10 16 11
