[A86] Re: ROM / RAM equates database

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

[A86] Re: ROM / RAM equates database


> Van: David Phillips <david@acz.org>
> 
> > - 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?

Okay, just a little shell history of the Ti83:

Ti's own 'send9(prgmXXX' required the program to be stored in ASCII-hex,
making it twice as big. The ROM loads the data of your program to a fixed
point.

Lateron Ti has helped a bit in making ZASMLOAD. Ti released the code of the
ROM call that did the 'squishing' and copying part, so domebody could make
a program that works the same exept for the 'squishing'. That program was
basicaly a 'send(9' ASCII-hex prog which would load the data of your
(non-ASCII-hex) program to the before mentioned fixed point.

Then AShell and SOS and some other shells were made, they weren't that
sophisticated, they only LDIR'ed the data of your program to the exec_ram,
and copied it back afterwards. VAT pointers are incorrect this way.

Ion did it a little better, since it used the ROMcalls _insertmem and
_deletemem to keep the VAT pointers correct. But it still did only copy the
data from inside the variable to the exec_ram, and moved it back lateron.
Crashing back to TIOS would almost always mean that your calc gets
unstable.

Venus copies the entier program-variable, such if you crash back to the
TIOS everything is still allright, no unstable TIOS. Another great thing is
that you can start program from the prompt.

Basicaly a Venus program looks like (on the Ti83):

------------
Send(9prgmO	(O is Thetat)
[..Venus header..]
[..Assembly code..]
------------

prgmO is just a small assembly program that contains a JP to the Venus
kernel. The kernel then looks which BASIC program was executing, and moves
the entier program just above the 'executing' prgmO. It modifies some
pointers so when the TIOS unloads prgmO and returns to your Venus *BASIC*
program, it *thinks* that there was a BASIC 'Return' command after the
'Send(9prgmO' in your Venus program.

And then I haven't even explained the header and libs... (hmmm, Venus libs
aren't 'relocatable', you need to use JR's and the such, lib-internaly...)
 
> > - 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?

Well, it's not THE compiler used in the GBDK (GameBoy Dev. Kit). It is
though the current compiler used there... Though Micheal Hope hasn't taken
a look at the GBDK's CVS-tree for a long time. (aka the SDCC version there
is old, very old)

When you look at the newest SDCC versions then you see that it has still
some internal compiler problems, and some problems with generating Z80 code
(Z80 isn't the primary target of the SDCC compiler). It lacks libraries and
startupfiles, currently it can be used for creating Z80 and 8051 ROM's, and
that's about it...

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

I know...

>  For example, there's no good way
> of doing relocatable code, libraries, separate modules, etc.

??? Not if you use TASM off coarse...

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

On the z88dk almost all libs are in Z80 assembly, not in C, I guess that's
what you mean?

>  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 :)

There is... (I think)

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

Same header format would be nice. You could then think of actually using
the library functions of shell. Now every shell uses a differen't format.
Some want you to add special datapointers to the libs, add
relocationtables, etc.
When you have just one system you can implement that (instead of needing to
add dozens of differen't supports for the different shells).

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

I know what a peephole-optimizer is...

Superoptimizers can be used to generate a RULES file for the
peephole-optimizer... You get it?

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

I already have some idea of making a basic 'synthesiser' as you called it
(I called it a 'Superoptimizer', as used by the GNU-community and some
universities). There are only some commands it will handle as 'breakpoints'
(code after that doesn't matter, and code before it must generate the same
register values).
These are JR/JP/CALL/RET, since I can't be shure of what it jump/calls/etc
to. And IN/OUT, since these affect the 'outside world' of the processor.

The main problem is that you can't optimize really good if you don't know
that registers may be 'lost' and which not. For example, calling a ROM
routine most of the times doesn't need all the registers as input. How do
you describe that in the code?

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

Keyword is 'Dune', and people who get it might think I'm a geek. But "geeks
rule the world" :-)

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

???

I mean 'time', in the way of 'What time I can spend on these projects'...

	Henk Poley <><
Follow-Ups: