[A89] Re: p55x

[Prev][Next][Index][Thread]

[A89] Re: p55x

On Sunday 14 September 2003 03:18 am, you wrote:
> What about people with 2.2 kernels? Debian stable still uses them by
> default, but they provide a package for 2.4 (2.4.18, I believe). Yet I
> have not seen the support for anything calculator-related even in the
> 2.4.21 configuration.
These are external kernel modules. But 2.2 is a good point.

> You mean you will require people to patch their kernel? Or are these
> standalone modules like the 2.2 PCMCIA modules? Anyway, I don't think
> that every user wants to build things from source, even on Linux. By the
> way, don't libticables and libticalcs work on other Unix derivates? I
> see at least FreeBSD on www.tilp.info. What about those?
These are loadable modules.

> Good luck with that.
> Have you actually read the GCC patch? It means you'll have to drop a lot
> of things: native float support, register-relative mode, F-Line ROM
> calls, ...
> If you mean you only want to drop the tigcc front-end and patch gcc
> instead, then OK, but you _really_ might want to work together with the
> TIGCC team in this case, specifically Kevin.
I mean drop the front end. But no, I haven't seen the gcc patch. Oops.

> > Real Programmers don't use IDEs.
> That is probably true, but what about newbies. (OK, not many newbies use
> Unix systems.)
Exactly. :-)

(from Jude Nelson)
> Since when?
Well, I don't, and I don't see a particular need. Of course, if you want to 
use the IDE, it's up to you, and I don't see it really conflicting with 
anything else here.

> > - Teach proper use of modular programming, assembler/C mixing, GNU
> > extensions, GNU make, and linking.
> The problem with modular programming (and with a lot of other things
> related to TIGCC) is the lack of space on calculators. It will hopefully
> become better in future TIGCC releases, but only due to very strong
> linker optimizations.
The issue with modular programming is really code readability. AFAIK, unless 
you de-inline things that would otherwise be inlined, it doesn't affect size 
or speed.
I don't mean totally breaking programs into independent modules, just into 
separate source files handing separate things. For anything over a certain 
size, this is a very good idea.

> > - (warning: compatibility breakage) Make API more ANSI/POSIXish.
> I don't exactly know what you mean. Make it compilable with '-ansi'? Or
> do you want to improve the ANSI-specific functions?
Make the functions more ANSI/POSIX like.

> > Remove evil monolithic header files.
> And do what? One header file for types, and others for functions? That
> sounds good to me, except for the compatibility breakage.
Yes, like ANSI/POSIX. I'm a purist, so sue me.
-- 
"I love deadlines. I love the whooshing sound they make as they go by."
	- Douglas Adams
Nick Tarleton - nickptar@mindspring.com - PGP key available
Follow-Ups: References: