[A86] Re: ROM / RAM equates database

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

[A86] Re: ROM / RAM equates database


> Van: David Phillips <david@acz.org>
> 
> > 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...)
> 
> Thanks for the explanation on Venus.  Sounds interesting.

Ti83 Venus header...

--------
#define vnFastCopy $FE6F	;
				;
	.org	$932C		;
	.db	"ç9_[?"		; send(9prgm0 (where 0 is theta)
#if Venus			; Venus
	.db	$0,$1,$1	; No description nor icon
#else				;
	.db	$1		; Venus Explorer (GUI of Venus)
	.db	icon-description	; lengthOfDescription+1
description:			;
	.db	"name"		; No zero term...
	.db	externals-icon	; heightOfIcon+1
icon:				;
	.db	icon		;
	.db	$2		; numberOfExternals+1 (maximum = 11d)
externals:			;
	; Example, the FastCopy-lib
	; $5   = program (Are filetypes the same on all Ti's?)
	; $FF = terminator
	.db	$5,"~FCPY",$ff

	;[..program goes here..]
--------

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

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)

> > 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...
> 
> In other words, it sucks, just like all the other compilers.  I took a
> look at ZINC (for the 85) and a small C port last night.

ZINC?

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

>  Both were very lacking
> in features, and produced terrible code.  Granted, I'm not saying it's
> easy to make an optimizing compiler, especially for the z80.  But you
> won't get anything efficient when you're outputting code during the
> parsing stage! The compilers I look at were really pathetic.  Is there
> anything better?

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.

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

> > >  For example, there's no good way
> > > of doing relocatable code, libraries, separate modules, etc.
> >
> > ??? Not if you use TASM off coarse...
> 
> What do you mean?  TASM can't magically create relocatable code for you. 
> No matter how you do it, it's going to be innefficient.

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

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 that it needs
to be adapted so it outputs in the Ti85 (and future Ti86?) format.

> > >  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?
> 
> No, not at all.  Again, if you don't remember what I'm talking about,
> then you might have trouble picturing it :)
> 
> void foo()
> {
>   asm
>   {
>     ... ; cool stuff here
>   }
> }
> 
> Something like that.  Where things like sprite routines, graphics code,
> etc., it's all done in assembly.  Anything time critical, or that needs
> to be small, you write it in assembly.  But it's much faster than writing
> the entire program in assembly.  And the generated code should be
> as close as possible to hand written assembly in terms of quality.

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.

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.

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)

C is only used for the program-flow.

> > 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).
> 
> Sure.
> 
> Not sure how you'd want to handle rom calls and such.  Probably have a
> macro for it, or a function wrapper that would get inlined.

--------
#define vnROMcallLib $xxxx	; A Venus external
#define ROM_CALL(adress)   call vnROMcallLib \ .dw adress

;[..Venus header..]

	;..code...
	call	vnROMcallLib
	.dw	$cccc
	;..more code..
--------

vnROMcallLib then needs to find where it is:

--------
;Already destroys DE and HL...
vnROMcallLib:
	pop	hl		; HL = *adress
	inc	hl		;
	inc	hl		;
	push	hl		; ROM returns to *adress+2
	dec	hl		; 
	dec	hl		; HL = *adress
	ld	d,(hl)		;
	inc	hl		;
	ld	h,(hl)		;
	ld	l,d		; HL = adress
	call	$nnnn		; call to a RET...
Label:				;
	dec	sp		;
	dec	sp		;
	pop	de		; DE = Label

	[calculate place in table, and look up]
--------

Or it could just add an offset-value:

--------
;HL gets destroyed...
vnROMcallLib:
	pop	hl		; HL = *adress
	inc	hl		;
	inc	hl		;
	push	hl		; ROM returns to *adress+2
	dec	hl		; 
	dec	hl		; HL = *adress
	push	de		; preserve DE
	ld	d,(hl)		;
	inc	hl		;
	ld	h,(hl)		;
	ld	l,d		; HL = adress
	ld	de,ROMoffset	;
	add	hl,de		; HL is calculated ROM adress
	pop	de		; recall DE
	jp	(hl)
--------

Okay, probably needs to be different since you would like to preserve as
much as possible registers...

> > I know what a peephole-optimizer is...
> >
> > Superoptimizers can be used to generate a RULES file for the
> > peephole-optimizer... You get it?
> 
> Show me some papers or books that describe this process :)

:-P

> The problem is determining what is equivalent.  If a flag is set
> differently, are they equivalent?  No, but does it matter?  It's very
> hard to tell without knowing the context of the code.
> 
> Anyone who has programmed in z80 for a while could much more easily make
> a list than a program.  Unless you know how to do pruning for it, for any
> sequence over a few bytes, it would take literally forever to run.

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?

> > 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.
> 
> What about flags?  How do you know if they necessary?

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

> > 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?
> 
> Look at the Watcom C/C++ compiler's assembly #pragma's for a good
> example of this.

SDCC has something like this, but very redumentary (although 'better' than
SCCZ80 [z88dk's compiler], since that one has virtually nothing like this).

> > Keyword is 'Dune', and people who get it might think I'm a geek. But
> > "geeks rule the world" :-)
> 
> Heh.  I missed that movie when they showed the remake on the Sci-Fi
> channel...

Books are always better than movies... :-p

	Henk Poley <><
Follow-Ups: