Recent changes to feature-requests

ARM Compiler support for SPIC

Dave Bacher — Tue, 02 Dec 2003 20:32:03 -0000

Sample Code:
test.c:
#include <PalmOS.h>
// nothing else needs to be in file to reproduce

[cygwin] c:/whatever$ arm-palmos-gcc test.c

Results:
Code fails due to OS_CALL macro that evaluates to __SPIC__

It's not a bug, because the compiler is working just
fine, but it prevents writing ARM code that calls into
PalmOS without thunking to 68k code running in
emulation. For games or multimedia apps, performance
can be much higher if the code doesn't have to thunk.

Debugging over USB Cable

Anonymous — Sat, 12 Apr 2003 11:56:12 -0000

Some devices as the M150 Zire do not have a serial port.

It would be great to have the possibility to debug
applications on these devices using an USB connection.

-Caspar
(seckendorff@alphatec.de)

build-prc: Indirect file input for arguments

Kevin Hunter — Fri, 31 Jan 2003 17:37:16 -0000

I have an application that has many, many small
resources. (It's a reference manual)

build-prc can't handle the number of PilRC .bin files on
the command line. The total amount of data isn't
immense - it's just broken up into lots of little resources.

If build-prc could take an @file syntax, in which "file"
contained the list of files to be bound (or even allowed
command line options to be included) this wouldn't be a
problem. As it is, in order to be able to bind the .prc file,
I'm having to resort to combining resources in a way
that's significantly complicating my code. (I'm trying to
avoid a separate database.)

Support for gdb/mi on gdb.

Steve Beaudoin — Sat, 18 Jan 2003 17:55:21 -0000

m68k-palmos-gdb don't recognise the -interpreter=mi
command line option, possibly because it as been
disabled. I am building a gdb debugger interface for
palm based windows/cygwin environment and gdb/mi
support would be greatly appreciated.

preprocessor defines for SDK version

Tim Hudson — Sun, 05 Jan 2003 03:58:27 -0000

With the usage of -palmos<VERSION> there should
be some way of determining what version of the SDK
is being used so that code which can handle multiple
versions can do so without the developer having to
make up their own defines to add to the compiler flags.

i.e.

echo foo | m68k-palmos-gcc -palmos3.5 -dM -E -

and

echo foo | m68k-palmos-gcc -palmos5 -dM -E -

should have something in the output which is
different.

Perhaps __palmsdk__ with a value of the version
multiplied by 10?

Automatic multi-segment applications.. implementation idea

Fri, 27 Sep 2002 05:39:38 -0000

This is cut-and-paste from my two posts to
prc-tools-devel list to which I got no replies.

First, regarding C++ code generation:
1. I have a larger project that uses exceptions. All
exception-related
data goes into the data segment. This makes my data
segment grow over 120kB!!

2. What's worse, gcc generates exception data for all
functions, even those that don't catch or throw
exceptions (and I've verified in the assembler output
that in such cases these tables aren't even referenced).

The solution: put exception-handling tables into the
same section as code, instead in the .data section.
This immediately follows with another feature request
(and solution idea) regarding limited code segment sizes:

I've devised a way that could make automatic
generation of multi-segment applications easy, without
external tools and manual sectioning of the code.

The approach would be this:
1. each compilation unit (.c file) goes into its own
section
2. when a subroutine X is about to be called:
- if the subroutine is in the same compilation unit,
normal code
(as is now) is generated; just a bsr X
- if the subroutine is in another compilation unit, the
compiler would generate indirect jsr via a lookup-table
(that can be in a segment of its own, not in the main
.data section). The pointer to that global lookup table
would be stored in a global variable (say
__$reloc_table) and some address register would be
loaded with it when the jump is about to take place (or
it can be dedicated just for that, if needed, say %a3,
%a4 if no -mown-gp is specified or %a6 if
-fomit-frame-pointer is in effect). Then something like

jsr X__$reloc(%a3)

can be generated.

3. Another tool would be written that would do the
following things:
- generate an assembly file with all relocation data
for all external
symbols, like this:

.section .sreloc
.org 0

__$reloc_table:
X__$reloc:
.long 0 # for subroutine X
Y__$reloc:
.long 0 # for subroutine Y

where 0 would be replaced with the offset of X from the
beginning of its section. The tool could generate the
file with the help with
nm (or via libbfd library, but with nm is easier if
using perl to write this tool) The tool would then
call the assembler to assemble the relocation table,
construct appropriate linker scripts and call the linker.

4. At run-time the startup code would check out all
code segments, and the relocation segment and apply
appropriate relocations (high 2 bytes of relocation in
reloc_table can be the segment number, while low 2
bytes can be the offset from the beginning of the
segment; the new table would be constructed at startup
and copied into new record when all base addresses of
all segments are known).

THE CATCH: I know how to do everything described above
(including writing the necessary startup code), but I
don't know how do modify the code generation in the
compiler. So if anybody is willing to give me a hand
here, I'd do the rest of the job.

======

Or is there any reason you people DON'T WANT to
implement automatic multi-segment applications and
usable C++ code generation? I can't believe that people
who hack gcc can't devise such a simple idea and
implement manual sectioning of the code instead... I
don't want this to sound as accusation, but a friend of
mine suggested that you may even have a deal with
Metrowerks so that they can continue to sell their
compiler...

Palm OS 5

Tony Yat-Tung Cheung — Thu, 15 Aug 2002 16:11:22 -0000

Will PRC-TOOLS support developing OS 5 applications
with ARM native codes?

PRC-Tools binary for OSX?

Marc Mennigmann — Thu, 11 Jul 2002 21:16:34 -0000

Since the PRC-Tools are UNIX based, are there any plans
to release compiled binaries for OSX? AFAIK this would
be the first noncommercial compiler for Palm appls for
ODX...

Thanks,
Marc

Further documentation on .def files

Jim Ramsay — Thu, 11 Apr 2002 04:56:16 -0000

I think it would be wonderful to get more
information on what a .def file can contian! I
couldn't find this in any of the documents I
received with the source or on the webpage.

I am aware of the
application { "App Name" CRID options }
and
multiple code { "seg1" "seg2" }
but am curious if any other things can be
controlled.