[A86] Re: Alternative Language compiler for the z80.

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

[A86] Re: Alternative Language compiler for the z80.



On Mon, 24 Sep 2001 21:19:11 -0700 "David Phillips" <david@acz.org>
writes:
> > (2) Java style object file production - In other words, one object 
> file
> > being produced for one source file.  None of this header file 
> buisness.

Do you mean to have a separate variable for each source file?  There's
about a 16 byte overhead per file, plus the extra code to call across
variable, and you can't store local data in _asm_exec_ram  (unless you
want to combine this with in-place execution)

Much of the inefficiency of the rom comes from the fact that the code is
split across multiple pages.
 
> > (6) Base Types - This part has perhaps bothered me the most about 
> language
> > X.  I've always loved programming in C and C++, but I've always 
> felt that
> > the choice of base compiler types was awkward.  I'm sure there is 
> an ANSI
> > standard for it, but just because it is standardized doesn't make 
> it feel
> > less akward.  You have int, char, float, long.  This might not get 
> a
> > positive response from my fellow programmers, but I suggest that 
> langauge
> X
> > have a single base type as the "byte".  To me this is simple and 
> elegant.
> > All other types would be derived from this somehow within the 
> language.
> 
> I agree.  I hate having to write "unsigned char".  It would be much 
> easier
> to write "uchar".  I am unaware of a portable header file that has 
> these
> defined (I think C99 has something about this, but I don't have any 
> info on
> it currently).

Not to mention that it's difficult to know exactly how big a variable
will end up in C.
How big is an int?  Could be 8, 16, 32, or maybe 64 bits, depending on
the compiler.  On the calc, this is always important.
If you could do a typedef byte int[2]; or something and still be able to
use it as a single value...  neato!
 
> > (7) Operator Support - This has also bothered me quite a bit.  How 
> should
> > operators be handled in the language.  It seems to me that 
> operators are
> no
> > more than syntatical sugar for "special" functions.  Usually I 
> percieve
> > "special" features as inelegant and unclean.  I've always leaned 
> towards
> > simple consistant interfaces.  C appears to provide two interfaces 
> for
> > simular things: functions and operators.  But I can't invision a 
> langauge
> > maid entirely of operators or one made entirely of function calls. 


Well, that depends.  On processor native types, operators represent
built-in instructions.  Essentially the same as a function, yet still
quite different.  Also, it's a much more natural way for a human to
describe math operations.

I agree that special cases are annoying (that's actually what I hated
most about basic, I think), but as long as you don't have operators for
stupid things, like say writing text, I think it works.

>  Just
> > take a look at LISP/SCHEME syntax for this idea taken to the 
> extream.  Yet
> I
> > don't know how the new language should handle this.

Ah, lisp...  I would love to see lisp (or something related) for the
calc, but I think that would pretty much require an OS with list support.

> floating point ROM call.  Although it could be beneficial to have 
> libraries
> shared between programs, it would probably be best to make every 
> program
> standalone, at least on the 86.  On calcs with shells that support 
> these
> features, alternative methods could be explored.

Using a library on the calc would be beautiful (not for simple rom call
wrappers, of course), but only if it was standardized and many people
used it.  You'd also have to include it with every program, but that
shouldn't be an issue.

-josh
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
Follow-Ups: