[A86] Re: ROM / RAM equates database

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

[A86] Re: ROM / RAM equates database


> Ti83 Venus header...

Looks good.  Very similiar to TI-86 headers for programs that choose to=20
include shell information.  One thing I would suggest is to not include=20
non-printable ascii characters as literals in code.  It might be useful t=
o=20
change those characters to their hex equivalents, as you never know what =
an=20
editor or mail program will do to them.

And speaking of mail programs, I started using KMail, and it rocks!  Linu=
x=20
finally has an equivalent to Outlook Express.  Would be nice if mail=20
viewing in separate windows was the same, but I suppose I could add that=20
myself if it's not in KDE 3 :)

> As 'library' you can use any sort of file; programs, lists, matrixes,
> etc. For programs it will setup a JP (3 bytes), for other variables a
> datapointer (2 bytes). Externals will be placed just after the executin=
g
> program.

I can see how that would be really useful.  I don't think any other shell=
=20
does this.  Did you create Venus?  If so, great work!

> Just thought of the possibility to make libraries (program variables)
> relocatable, but that would make it only more difficult... Plus Venus
> would grow that big that it won't propperly fit in the stack anymore...
> (another pro for this shell, it takes virtually no space, usable stack =
is
> smaller though, so possible stack-overflow)

Programs are relocated to a fixed location, right?  And libraries are=20
always located to a fixed location relative to the end of the program? =20
Then in that case, they are static to the program.  You would merely need=
=20
to put a variable at the end of your program, and add to that the startin=
g=20
offset of any address in the library, plus the starting offset of the=20
library.  Things inside the library wouldn't be able to statically addres=
s=20
things in the library, but the program could.  Very useful for levels and=
=20
such.

> ZINC?

http://www.ticalc.org/pub/dos/asm/zinc8-30.zip

Look in ticalc.org in the /dos/asm section, if you want to see an example=
=20
of how not to make a compiler :)  Don't get me wrong here.  I think it's=20
great that someone wrote something and released it for free with source,=20
but that still don't make it decent or usable.

> Small-C compiler would probably be Ti8xcc (sucks less than other compil=
rs
> found at Ticalc.org)? Or anything Ti85 related, UsGard Small-C?

http://www.ticalc.org/pub/dos/asm/ti8xcc.zip

I will admit that I didn't bother running any of these utilities.  The ma=
in=20
reason for this is because at home, both my computers only have Linux, an=
d=20
I didn't feel like trying to compile anything (they didn't come with=20
Makefile's, and would likely not compile cleanly anyway).  Just looking a=
t=20
the source will give you a hint at how poor the generated code will be.

> Compiling without intermediate language IS bad, I know. SDCC uses an
> intermediate language and is such potentialy good. From what I've
> heard(!), they still have some problems in 'overoptimizing' code...
> switch() statements that never run the last statement is one of these
> things I have heard(!) of.

Is the code clean enough to easily be able to work with it?

> SDCC is currently in the Top-20 of most active projects on SourceForge.
> So it is probably going to be allright in a half a year or something.
> Another compiler I want to get my hands on the the Amsterdam Compiler K=
it
> (ACK), that was 'THE' compiler used on MINIX (a free Unix clone, in the
> first years of Linux you needed to boot MINIX first before you could
> start Linux version < 1.0.0). There were/are rumours that this compiler
> is going to be GPL'ed.

I know about MINIX :)  Is SDCC likely to get better?  MINIX was for x86,=20
not z80.  Or did it do both?  And for the record, THE compiler in the DOS=
=20
days was Watcom C/C++.  I believe the last CPU it optimized for was the=20
Pentium, and I would be surprised if any compiler would beat it for those=
=20
targets.  A good compiler to check out would be one for CP/M, or possibly=
=20
the TRS-80.  I believe that Justin Karnages got his hands on one for CP/M=
=20
and used it for the first version of Joltima, before he decided to write =
it=20
completely in assembly.

Another question, possibly more important, is if C is the language to be=20
going after.  It doesn't exactly lend itself to ideal code on the z80.

> Umh, I meant to say "If you use TASM, then it can't be done, off coarse=
",
> me being Dutch... ;-)

Ahh :)

> Assemblers that use linkers are most of the time capable of 'collecting=
'
> all the 16bit adress-pointers themselves and putting them in a nice
> table. I came to the conclusion that Z80ASM has this too. It is just th=
at
> it needs to be adapted so it outputs in the Ti85 (and future Ti86?)
> format.

My gameboy assembler and linker do this too.  It let you essentially have=
=20
transparent access to different ROM banks from page 0, with the addition =
of=20
a special RST routine or two (it's been at least a year and a half since =
I=20
worked with that stuff).

> So it's more or less what I thought you ment...
>
> On the z88dk that would be:
>
> --------
> void foo()
> {
> #asm
> ; cool stuff here
> #endasm
> }
> --------
>
> Basicaly just a C-wrapper around an assembly function.

Right. Not sure I like that format for inline assembly.  Seems to be=20
cleaner if it's an extended keyword.

> You only want to use even more assembly, mixed with a higher language (=
I
> guess). Which is off coarse possible, but only if you know what the
> compiler does exactly. Since you need to interact between the code
> generated by the compiler and your assembly code.

Exactly.  This is why C might not be the best language for the job.  The=20
programmer needs to know what the compiler is going to do, and you=20
shouldn't have to be an expert to figure it out.  And the programmer shou=
ld=20
help the compiler generate the best code by giving it hints on what the=20
inline assembly will do.

> Oh, and with libs I mean the sort that get's linked in with a linker
> after the assembling process, not shell libraries. (Venus libs are off
> coarse shell libs)
> z88dk's libs are almost all written in the way described above (most of
> the time as just plain *.asm file [no C-wrapper around it], but that
> doesn't matter)

And I'm saying that if you link after assembling, then you don't get near=
=20
optimal code, space or speed wise.  Space usually more important, but on=20
the z80 in most cases the smaller code will be the faster code.  There is=
=20
no need for any linking.  The assembler should generate the final object=20
code, since it should be statically relocated.

I had some interesting ideas for efficiently doing functions, so that the=
y=20
would be easily usable in assembly, and efficient overall.

> vnROMcallLib then needs to find where it is:

Maybe it's just really late, but none of that made any sense to me.  That=
's=20
for a ROM call?  the "call $nnnn" is never modified, so what is it callin=
g?=20
Why can't you just call it directly?

> > Show me some papers or books that describe this process :)
> >
> :-P

As of late, I have been discovering that essentially everything has alrea=
dy=20
been done, and was written about years ago.  Maybe that's because I'm=20
getting older, or maybe I'm just lazy.  The more you learn, the less you=20
know.  I'm not saying we know everything about compilers and optimizers,=20
but this problem has been studied by some very smart people (much smarter=
=20
than me) for the last fifty years.  If it hasn't been done, then I'm sure=
=20
there's a reason.  Either way, there has to be something written about it=
=2E =20
chapter nine of "Compilers: Principles, Techniques, and Tools" has nothin=
g=20
on the subject.

> Also have though about some Seti@home thingy, where the PC was used as =
a
> medium to distribute OP-code sequences, and the people would need to
> optimize the code... The problem here is, how to get enough people
> (you'll never have enough), how to check for errors?

Again, it's pretty futile, as there are very few completely equivalent se=
ts=20
of instructions.  And, there is no mathematical way to prove that a given=
=20
run of instructions is optimal (Compilers points out this fact), other th=
an=20
testing literally every possibility.=20

This is similiar to determing the "best" chess move.  I would guess that =
it=20
would be technically possible to compute all possible moves for a game of=
=20
chess from any given position, including the starting position.  At that=20
point, chess becomes similiar to tic-tac-toe in the fact that the player=20
going first would win, or else the game would always be a draw.  I have=20
never seen anything on this specific subject, though I would guess someon=
e=20
has considered this before.  It would be interesting to see the results o=
f=20
that.  I wonder if we will know the answer to that question by the end of=
=20
our lifetimes.

When you think about all the games like tic-tac-toe and chess, you realiz=
e=20
that chess is actually fairly simple.  Consider all possible chess games,=
=20
compared to, say, all possible StarCraft games, for a specific map. =20
Obviously is impossible to make a game like that completely balanced, but=
=20
which side is really the best?

> You couls also say: "What about HL/DE/BC?  How do you know if they
> necessary?"

Exactly.  You need heuristics which are only available when working with=20
generated code.  I suggest reading chapter nine of Compilers for an in=20
depth look at the subject.  It gives algorithms and strategies for=20
generating correct, efficient (not optimal, which is impossible) code.=20

> > Heh.  I missed that movie when they showed the remake on the Sci-Fi
> > channel...
>
> Books are always better than movies... :-p

I agree.  Funny how when you mentioned Dune I immediately thought of the=20
movie.  I probably only read about 1/3 of that book (which is funny,=20
because one of my brothers is in middle school and recently told me he re=
ad=20
it).
References: