[A86] Re: ROM / RAM equates database
[Prev][Next][Index][Thread]
[A86] Re: ROM / RAM equates database
> - Making Venus-like shells for all of the Z80 Ti's (Venus is a Ti83 shell)
> Assembling/compiling for the different calcs would be EASY,
> Since the headers would be more-or-less the same.
> [relation to ROM / RAM database]
What exactly is a Venus shell? Is there anything special about it, as
opposed to, say, Ion?
> - Better Z80 C compiler
> Helping the SDCC, and adding the z88dk lib to it would be the solution
> at the moment.
What is the status of that project? Is that the same compiler used for the
Game Boy? I've thought about this a lot. C isn't exactly the best language
for development on the calc. It has a lot of features that are not
necessary, and things that can't be done. For example, there's no good way
of doing relocatable code, libraries, separate modules, etc. Perhaps a
simpler C like language that was geared towards generating optimized code
would be better. If you ever saw Turbo Pascal demos written in the late
80's and early 90's, then you know what I'm talking about. The programs
would be mostly inline assembly, with Pascal just as the glue holding it
together. Something like this would be very nice to program in, and would
generate optimized code. I might actually still write a calc program from
time to time if there were something like this :)
If someone or a group is interested in designing this language, I would be
willing to implement the compiler and toolchain for it. It would be very
preferable to have this language be context free, in order to keep the
parser from being over complicated. Depending on how complicated the
language is, it might even be possible to have an on-calc compiler.
> [Venus-like shells would be handy for the compiler]
Please explain.
> - Z80 Superoptimizer
> A superoptimizer is basicaly a program that will search for
> faster/smaller
> code than the one you gave it. Inputting $00 till $FFFFF..F would
> generate
> a list wich can be used for instantanious code optimizations.
> [relation to C compiler]
This is known as a peephole optimizer. This is generally the last step in a
compiler's code generation phase. The problem with peephole optimizers is
that they are not very effective unless you have some guarantees about the
code being optimized. Generally a peephole optimizer is a simple search and
replace list. You must assure that an output is equivalent to the input.
With hand written code that can by nature do anything, this is very hard, if
not impossible, to ascertain. This is a very similiar problem to a
dynamically recompiling emulator, or a recompiler (compile binary code from
one platform into binary code for another). A compiler will know what
values are what at a certain point in the code, so it does not have to make
assumptions that could generate incorrect code.
Another method is a synthesiser, but such a program would likely have to run
for a very long time for any non trivial amount of code. There are pruning
methods that can be used to increase the running time, but I don't know of
any sources that describe these algorithms. It is difficult to do this for
an instruction set as large as the z80's, and as before, it is basically
impossible to verify that a generated output is equivalent to the input.
The ficticious language mentioned above should have a method for the
programmer to tell the compiler which registers are modified by a block of
inline assembly, and possibly what the ending values are, if they are known.
This would allow the compiler to generate optimal code.
> - Starting a Mentat/counselor school
> Really nothing Ti nor Z80 related, so never mind...
> More a longterm project
Huh?
> Main problem: time...
Yes. It is unfortunate that this sort of thing isn't directly related to
many current technologies. Even embedded systems now are using powerful
cpu's and have plenty of ram.
References: