Hi all. I just wanted to write and say how much I love David Williams'
Multilink: http://www.djw.org/product/palm/multilink/
I've come back to my old PalmOS programming after a few years and the 32K
limits in my code were right where I left them, at 31.K. So I read
several very detailed d
> Hi all. I just wanted to write and say how much I love David Williams'
> Multilink: http://www.djw.org/product/palm/multilink/
>
> I've come back to my old PalmOS programming after a few years and the 32K
> limits in my code were right where I left them, at 31.K. So I read
> several very de
Multilink seems to be very cool. Maybe it's time to resurrect it -- I
have a LARGE code base that I'd like to move over to gcc, but modifying
all the C++ classes to declare the segment into which each one should
go is insane.
I had not heard of Multilink before, but this is definitely something
On Sunday 08 December 2002 07:54 am, Florent Pillet wrote:
> Multilink seems to be very cool. Maybe it's time to resurrect it -- I
> have a LARGE code base that I'd like to move over to gcc, but modifying
> all the C++ classes to declare the segment into which each one should
> go is insane.
>
> I
> I also had experienced Multilink a few years ago in playing with the
Yanoff
> project. IIRC it *had* a limitation on only being able to debug code in
the
> first segment. Now David has a clever method to fix that, and since he's
> released the 0.3 version which is prc-tools 2.x compatible, it w
On Sunday 08 December 2002 12:07 pm, Aaron Ardiri wrote:
> but really guys, whats the problem with the current multi-segment
> capabilities of prc-tools? if you do what most developers do, and,
> that is define function prototypes at the top of your files, it isn't
> rocket science to add the __at
> I was going to try it, but then I started reading about needing assembler
> stubs & stuff. Perhaps that's stuff I don't really need to know, but
still,
> I really wanted a solution where I didn't have to touch my sources.
>
> Let me ask you a question about capabilities though. Does prc-tools 2
So far I've never needed to worry about my code size. I like developing
small, very specific applications. Last time I checked, my largest
application was aroun 27K... but I still use multigen even though I don't
have to. :P
> globals :) eek :) hehe - you can get around them with good design
On Sun, Dec 08, 2002 at 12:23:01PM -0500, Chris Faherty wrote:
> Let me ask you a question about capabilities though. Does prc-tools 2.x
> native multi-segment support work without globals?
You might want to consider reading the documentation.
The answer to this question is even to be found in t
On Sunday 08 December 2002 12:32 pm, Aaron Ardiri wrote:
> globals :) eek :) hehe - you can get around them with good design
> (ie: use feature pointers to allocate a chunk of memory) :P in regards
> to multilink, i wonder how it could be adapted to support ARM code :)
> esp. if your solving these
> On Sun, Dec 08, 2002 at 12:23:01PM -0500, Chris Faherty wrote:
> > Let me ask you a question about capabilities though. Does prc-tools 2.x
> > native multi-segment support work without globals?
>
> You might want to consider reading the documentation.
>
> The answer to this question is even to b
> > globals :) eek :) hehe - you can get around them with good design
> > (ie: use feature pointers to allocate a chunk of memory) :P in regards
> > to multilink, i wonder how it could be adapted to support ARM code :)
> > esp. if your solving these globals issues with hacks/launch codes
>
> I beli
On Sunday 08 December 2002 01:12 pm, Aaron Ardiri wrote:
> but, based on what chris was 'hinting' was that using multigen doesn't
> do so :) that makes it very interesting. especially for armlet builders.
> it has been a long time since i did use multigen, maybe chris can fill
> us in on the capab
> On Sun, Dec 08, 2002 at 12:23:01PM -0500, Chris Faherty wrote:
> > Does prc-tools 2.x native multi-segment support work without globals?
On Sunday 08 December 2002 01:00 pm, John Marshall wrote:
> The answer to this question is even to be found in the Palm OS Companion
> (under "Responding to Ot
I'm not thrilled at the idea of going modify tens of C++ class header
files, especially when this is a library frequently updated (POL). This
is what I find insane. Multi-segmentation is perfectly handled by CW
which does it properly, and I don't see any valid reason to have to
declare where ea
> I'm not thrilled at the idea of going modify tens of C++ class header
> files, especially when this is a library frequently updated (POL). This
> is what I find insane. Multi-segmentation is perfectly handled by CW
> which does it properly, and I don't see any valid reason to have to
> declar
I just read the flurry of postings on Multilink.
Here are my 2 cents worth based on trying to adapt my multi-segment gdb
patch to multilink 0.3.
- As Chris Faherty pointed out, you need to patch the gdb add-symbol-file
command to make it understand the expressions used in the script
produced b
> > I'm not thrilled at the idea of going modify tens of C++
> > class header files, especially when this is a library
> > frequently updated (POL). This is what I find insane.
> > Multi-segmentation is perfectly handled by CW which does
> > it properly, and I don't see any valid reason to have to
If you have a patch for multilink, send away! I'm interested... I want
to peek at the source code want check what needs to be done -- maybe it
will be simpler doing that than modifying gcc (I already started
examining the prc-tools patches to gcc to determine how I could change
this to specify
Blake Winton <[EMAIL PROTECTED]> wrote:
> The ability to tag each function, while useful, is at too low a level
> of granularity for me (and Florent) to use, so I've been using
> Multilink. (I've got a patch for the libraries it comes with, so if
> anyone is going to start maintaining it again, p
20 matches
Mail list logo
