{$IFOPT OPTIMIZE SPEED}
-- write code which save on cycles
{$ELSE}
-- write code which save on size
{$IFEND}
That is on Pic Micro Pascal - great option!
If user run out of space, can chose the other option. Can be this made
optional on specific local code, and not global at entire code? In PMP
is possible.
You can mark a beginning of code with:
{$OPTIMIZE SPEED}, and so on...
I think this can be a great target for JAL and Jallib...
Kyle, I missed this one :-D
PMP is indeed a little jewel regarding to features. As JAL shinning at
resulted code size (but not much difference between the two).
On Jan 8, 10:35 am, Oliver Seitz <[email protected]> wrote:
> > What we have here is some basic point for generic
> > libraries. Resources
> > are ram, flash, stack and cpu cycles. Which one is the most
> > important?
> > I guess the one you run out of first.
>
> I fully agree here. And more, cpu cycles can be important in some cases, but
> it is the only problem that can be solved by waiting. If you're out of
> memory, the program won't run at all.
>
> My suggestion to change (or add another) print.jal was made to reduce on
> *all* of the named resources. I did not succeed (yet) in reducing flash and
> stack for dwords, however.
>
> > I think there is litte problem with a dword that takes
> > 500ms if you
> > only print it once a day...
>
> Agreed! :-)
>
> > > Maybe a documentation header for every function inside
> > libraries can
> > > help actual and future developers about readability.
> > I do not object to more complex algorithms if the result is
> > better. My
> > point is complex algorithms are more likely to catch a bug
> > when
> > implemented. And on average, 60% of each bugfix also
> > introduces a new
> > bug. So I disagree with the view that code is only read
> > once and
> > clarity is not an issue. It is important and gets even more
> > important
> > if complexity increases.
>
> Also right. My suggested algorithm is not really complex, it merely lacks the
> elegance of the current version ;-) And, concerning the print library, it
> handles a finite set. It will take weeks or so, but we can try every one of
> the 6.442.450.944 numbers it can process and check if the result is correct.
>
> Of course, in general I agree with your points.
>
> Greets,
> Kiste
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
