Subject:
|
Re: NQC for Palm
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 4 Apr 2001 02:52:13 GMT
|
Viewed:
|
1177 times
|
| |
|
|
In article <3ACA6077.70509@3dnature.com>, xenon@3dnature.com wrote:
> Well, I just got some bad news from Dave 'NQC' Baum.
> Apparently he's a Palm developer, and he won't touch
> the project, because of architectural limitations in
> the Palm OS. Apparently NQC needs a lot more dynamically-
> allocated memory than the PalmOS can handle.
>
> I'd heard of the 32k limit, but I didn't realize it
> was quite so severe. I thought it was something that
> could be more or less coded around, but it seems like
> it would be disasterous for NQC.
I just did some measurements of heap usage for NQC, and it isn't quite
as bad as I feared. Compiling a trivial program without including the
standard API uses about 11K. If you include the standard API, this
grows to about 64K. For a modest program (linebot3.nqc from my book)
you need 84K.
These numbers do not take into account the amount of global data (which
must come from the heap on Palm), nor the buffers allocated by the lexer
and parser (they go through malloc() and I only instrumented calls to
operator new).
There will be some small space savings on Palm because of 2 byte
integers, but it may not by too dramatic. A lot of the data in the
parse tree is either pointers or byte arrays - both of which would
occupy the same amount of space on Palm.
The global data could be problematic. Its about 54K right now. The key
would be turning as much of it as possible into constant resource data
(which is much less limited), and only put the non-const data into
actual global data. 25K for the API file is one good resource
candidate. There's probably also about 12K of parser/lexer tables which
could be resourced. Strings account for about 2K, and they could be put
in the code segment rather than using up global space. Just to ballpark
things, lets say we could get global data under 10K. (this seems high
considering there isn't much actual global data in NQC, but I think it
may be a consequence of the v-tables getting stuck in the data segment -
perhaps there is a work-around)
So, getting everything running with 100K of heap (high end Palm) is
tight, but feasible. 32K (minimum Palm) is right out. Bear in mind
that Palm strongly discourages using 100K of heap...altough the high end
devices have that much heap, its really there so things like TCP can
take a chunk of it and still leave room for the app. Using that much in
an app is risky.
To be honest, NQC just wasn't designed to run in such a small space.
Everything about the parse tree and code generation is fairly
object-intensive, which means lots of small allocations (which are not
necessarily very efficient memory-wise). Allocation pools could help
eliminate some of the wasted overhead.
If someone wants to tackle this, let me know. Personally, although I
develop on the Palm a lot, I just wouldn't find NQC-Palm useful enough
to warrant the work. However, if someone else wants to do it, then I
can at least help them figure out where the memory is going and perhaps
how to trim it.
Also, just getting a baseline build with the 68K compiler targetting the
Palm would be helpful. I'm just guessing at the global data numbers,
and there are probably a few options that could be used to reduce this.
Dave Baum
--
reply to: dbaum at enteract dot com
|
|
Message has 1 Reply:
 | | Re: NQC for Palm
|
| (...) Of course on my Agenda Palmtop - it took little more than typing 'make' to port it. <smug grin> (...) So the Palm is big-endian? I didn't know that. Won't that also cause problems for NQC porting...does NQC run on any other big-endian (...) (24 years ago, 4-Apr-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: NQC for Palm
|
| Well, I just got some bad news from Dave 'NQC' Baum. Apparently he's a Palm developer, and he won't touch the project, because of architectural limitations in the Palm OS. Apparently NQC needs a lot more dynamically- allocated memory than the (...) (24 years ago, 3-Apr-01, to lugnet.robotics)
|
4 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
