[A86] Re: ROM / RAM equates database
[Prev][Next][Index][Thread]
[A86] Re: ROM / RAM equates database
> Van: David Phillips <david@acz.org>
>
> > 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 :)
Ah well, your e-mail looks horrible now. With all these '=nn' things which
should stand for <LF> and the rest. I know that is because of MY
mailprogram being old...
If someone knows a good e-mailer for Windows and not being Outlook
(Virusses) or Eudora (just to much options), I would be happy to take a
look at it...
> > 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!
No, Tijl Coosemans did it. I just shout around a bit that it is such a
great shell :-)
> > 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.
Don't say that too loud! That would mean that I would get a LOT of troubles
in sustaining Venus support... Ever tried a to convince a linker to add a
certain lib at a certain place? (most of them do have an option to take the
startupfile first, thank god!)
It might be that Z80ASM is capable of that though...
Oh and another problem, you can use up to 17 externals, if I'm not
mistaken. Which would need at max. 17 'pointers'. I don't really know how
to tight everything up in this case. Especialy since I don't know the size
of the libs (can even change with newer versions, off coarse).
Oh, the externals do get a JP/pointer setup at a fixed adress, I could use
that one (but the lib wouldn't know it)... Basicaly these are
starting-offsets...
> > 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.
Didn't know about that one...
> > 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?
See for yourself... http://sdcc.sourceforge.net/ , they also have a
CVS-tree (for the most current source) and Win/Linux snapshots.
> > 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?
Google => "Amsterdam Compiler Kit"
See for yourself, it has Z80, x86, and some other processors. Modula 2, C,
Pascal, etc. frontends are also present. The pricetag is only a *bit*
high...
> 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.
"That's not my problem"... :-P
> > Umh, I meant to say "If you use TASM, then it can't be done, off
coarse=
> ",
> > me being Dutch... ;-)
>
> Ahh :)
:-)
> > --------
> > 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.
I'd say "Seems non-ANSI to me"...
> > 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.
If you know any such language... Your "language X" off coarse, but from
what I've seen it would be horrible to build a compiler for that (when you
wnat to implement all the things you stated)
> > 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.
You really need to check out one of the Small-C compiler found at
Ticalc.org. Then you would know that linking is much better than just
needing included everything. You then most of the time include too much
code, or you could put everything in dozens of smaller include-files, which
the programmer should get to know what to use. See Ti8xcc for a good
example. I have worked with that one for about a year.
The other option (used in TISCO), is to scan lateron which code is useless,
so you are then doing some sort of 'reverse linking'.
> 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?
$nnnn is an adress where "JP vnROMcall" is stored that has been setup by
Venus... I thought you wanted a solution for the ROM_CALLing on the Ti82
and Ti85?
ROM calls on the Ti73/83(+)/86 are documented by Ti, so that wouldn't be a
problem I think.
> > > 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.
Google => "Superoptimizer" (also try changing the 'z' to an 's')
There's some site about some students projects. Another site of the GNU
superoptimizer (optimizes for the SPARC, MC68000, MC68020, M88000, POWER,
POWERPC,AM29K, I386, I960 (for i960 1.0), I960B (for I960B 1.1), PYR,
ALPHA, HPPA and SH), can send you sourcecode of this one. And some site
about a PIC superoptimizer, have this sourcecode too... Pretty much
evidence of it's existence, I think...
> 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.
The chess game has been 'calculated' before (I've read in "Pythagoras", a
Dutch maths-magazine)... It is just that cashing (what you litterly do
then) is tremendous slow when there is that gigantic amount of data to
scan. I guess the chess game outcomes haven't been analysed completely,
since THAT would take a long time. I guess that also what you wanted to
say, analyzing is the main problem.
> > 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
Where to get that book? "Compilers" is a very general title, I guess there
are about a dozen of these around.
> > > 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).
Nice to see that I'm not the only geek who reads that 'much'. :-)
People at my school bashed [right word?] me because of reading 5+2 books of
let's say 500 pages. And then I've also read H2G2 (relatively small, but
dozens of things to 'see'), about all books of David and Leigh Eddings, The
Hobbit and off coarse, Lord of the Rings... This seems to be fairly
abnormal to most people... :-(
Henk Poley <><
Follow-Ups: