[A89] Re: p55x

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

[A89] Re: p55x

> Or, Proposal for Modernization of 68K Calculator Development on Unix.
> Windows people who want to reap any bounty should use Cygwin or MinGW
> until such time as they get a real operating system.

Well, Cygwin and MinGW are certainly much worse than pure Windows: very
slow and buggy. But yes, for people who know the Unix world, they are
usable.

> Improve TiLP and such.
> - Trash libticables, or greatly reduce. Require kernel module for
> black, parallel, USB links.

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.

However, people with Debian stable might not install TiLP anyway. Or
you'll have to backport all bugfixes to the Debian package on
www.tilp.info (wherever it is).

> - Improve kernel module build process. (This is the only thing I've
> already done.)

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?

> - Prettify file selector (among other things). At least make it start
> in CWD as opposed to home directory, and make it not show hidden files
> (if it does, which I think it does.) Allow entry of pathnames instead
> of click-o-rama.- Get rid of debug gibberish. Provide for totally
> quiet non-interactive mode.- Squash compatibility issues. Allow to
> work beside GtkTiEmu.

That sounds good (I think ;-)).

> Building.
> - Trash specialized TIGCC. Replace with direct build from GNU sources,
> plus some libs and headers.

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.

> Real Programmers don't use IDEs.

That is probably true, but what about newbies. (OK, not many newbies use
Unix systems.)

> - Patch GNU as to accept a68k syntax.

That is a good idea.

> - 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.

> - (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?

> 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.

-- 
Sebastian Reichelt
Follow-Ups: References: