f



C vs Forth on the Z80 (or 8080)

I'm posting this here because I suspect that this is one of the few
newsgroups where people might actually know the answer...

I want to write a program for a Z80 platform. (Potentially running CP/M,
although that's not terribly relevant.) It needs to be efficient and small.

I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
another language. Normally I'd write this sort of thing in C, except that C
compilers for the Z80 produce lousy code, in part due to the Z80's design.

Would I be better off writing in Forth instead?

Forth will generate threaded code that will need to be interpreted, which
produces an immediate performance hit. *However*, given that Forth
interpreters are damned fast, and that the C code we're comparing it with
is very bad, I think there's a reasonable chance that they'll be within the
same order of magnitude at least. Plus, Forth code is very dense and my
Forth system might well be smaller than my C system.

Does anyone have any experience of Forth on the Z80 who could comment? How
about recommendations on a Forth runtime? I was thinking of using FigForth,
as being small, simple and free, but I appreciate it's probably not very
highly optimised.

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | C:\DOS, C:\DOS\RUN, RUN\DOS\RUN
| (dg@tao-group.com) | 
+- www.cowlark.com --+ 

0
dg (326)
6/14/2005 5:17:22 PM
comp.os.cpm 3422 articles. 0 followers. Post Follow

90 Replies
3632 Views

Similar Articles

[PageSpeed] 41



"David Given" <dg@cowlark.com> sez...
>
>I'm posting this here because I suspect that this is one of the few
>newsgroups where people might actually know the answer...
>
>I want to write a program for a Z80 platform. (Potentially running CP/M,
>although that's not terribly relevant.) It needs to be efficient and small.
>
>I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
>another language. Normally I'd write this sort of thing in C, except that C
>compilers for the Z80 produce lousy code, in part due to the Z80's design.
>
>Would I be better off writing in Forth instead?
>
>Forth will generate threaded code that will need to be interpreted, which
>produces an immediate performance hit. *However*, given that Forth
>interpreters are damned fast, and that the C code we're comparing it with
>is very bad, I think there's a reasonable chance that they'll be within the
>same order of magnitude at least. Plus, Forth code is very dense and my
>Forth system might well be smaller than my C system.
>
>Does anyone have any experience of Forth on the Z80 who could comment? How
>about recommendations on a Forth runtime? I was thinking of using FigForth,
>as being small, simple and free, but I appreciate it's probably not very
>highly optimised.

You appear to believe that C is always compiled and that Forth is 
always interpeted.  There are a few C interpeters and a lot of Forth
compilers.




0
nospam21 (19047)
6/14/2005 5:42:54 PM
Kewpy wrote:
> "David Given" <dg@cowlark.com> sez...
> 
>>I'm posting this here because I suspect that this is one of the few
>>newsgroups where people might actually know the answer...
>>
>>I want to write a program for a Z80 platform. (Potentially running CP/M,
>>although that's not terribly relevant.) It needs to be efficient and small.
>>
>>I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
>>another language. Normally I'd write this sort of thing in C, except that C
>>compilers for the Z80 produce lousy code, in part due to the Z80's design.
>>
>>Would I be better off writing in Forth instead?
>>
>>Forth will generate threaded code that will need to be interpreted, which
>>produces an immediate performance hit. *However*, given that Forth
>>interpreters are damned fast, and that the C code we're comparing it with
>>is very bad, I think there's a reasonable chance that they'll be within the
>>same order of magnitude at least. Plus, Forth code is very dense and my
>>Forth system might well be smaller than my C system.
>>
>>Does anyone have any experience of Forth on the Z80 who could comment? How
>>about recommendations on a Forth runtime? I was thinking of using FigForth,
>>as being small, simple and free, but I appreciate it's probably not very
>>highly optimised.
> 
> 
> You appear to believe that C is always compiled and that Forth is 
> always interpeted.  There are a few C interpeters and a lot of Forth
> compilers.
> 
> 
> 
> 
Forth on a Z80 based m/c can be quite fast & efficient - interpretation
only takes place during the addition of new words (ie. program segments)
into the dictionary. My home pages*** contain some info w.r.t. the
Jupiter Ace, a Forth based micro on which games etc. were written
in Forth. I have experience of various Forth implementations on Z80,
including that running under CP/M. NB: Forth was originally designed
for real-time control etc. of Radio Telescopes etc! (IIRC)

Given that you appear to have more 'C' experience you might like
to try one of the "Small C" compilers/libraries esp. if you're
also intending to use CP/M - these are integer only, but most of
the library routines are effectively assembly (these compilers often
produce assembler files for subsequent assembly by a provided
assembler).

	Regards, Trev.
***http://www.cpmspectre.pwp.blueyonder.co.uk/
0
6/14/2005 6:30:39 PM
David Given wrote:
> I'm posting this here because I suspect that this is one of the few
> newsgroups where people might actually know the answer...
> 
> I want to write a program for a Z80 platform. (Potentially running CP/M,
> although that's not terribly relevant.) It needs to be efficient and small.
> 
> I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
> another language. Normally I'd write this sort of thing in C, except that C
> compilers for the Z80 produce lousy code, in part due to the Z80's design.

No, there are excellent compilers for the Z80.

> 
> Would I be better off writing in Forth instead?
> 
> Forth will generate threaded code that will need to be interpreted, which
> produces an immediate performance hit. *However*, given that Forth
> interpreters are damned fast, and that the C code we're comparing it with
> is very bad, I think there's a reasonable chance that they'll be within the
> same order of magnitude at least. Plus, Forth code is very dense and my
> Forth system might well be smaller than my C system.
> 
> Does anyone have any experience of Forth on the Z80 who could comment? How
> about recommendations on a Forth runtime? I was thinking of using FigForth,
> as being small, simple and free, but I appreciate it's probably not very
> highly optimised.
> 

They (C and Forth) are both excellent choices for the Z80. Pick the one you
like. If you don't like the C compilers you picked, find another one. The
worst compiled C is going to generate code better than the best interpreted
Forth.

The true power of Forth, especially on a small system like the Z80, is being
able to assemble/compile it yourself, and modify it yourself. The true
"power forth" users I have met all have their own custom forth installation.

Its also true of C users, but not as common, probally because C compilers
are a bit more difficult. However, C and small CPU with unoptimized compilers
were a good match, it gives you reasonable (but not outstanding) code, and
a smallish compiler that is easy to run and maintain in 64kb.

0
6/14/2005 6:39:02 PM

Kewpy wrote:
> "David Given" <dg@cowlark.com> sez...
> >
> >I'm posting this here because I suspect that this is one of the few
> >newsgroups where people might actually know the answer...
> >
> >I want to write a program for a Z80 platform. (Potentially running CP/M,
> >although that's not terribly relevant.) It needs to be efficient and small.
> >
> >I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
> >another language. Normally I'd write this sort of thing in C, except that C
> >compilers for the Z80 produce lousy code, in part due to the Z80's design.
> >
> >Would I be better off writing in Forth instead?
> >
> >Forth will generate threaded code that will need to be interpreted, which
> >produces an immediate performance hit. *However*, given that Forth
> >interpreters are damned fast, and that the C code we're comparing it with
> >is very bad, I think there's a reasonable chance that they'll be within the
> >same order of magnitude at least. Plus, Forth code is very dense and my
> >Forth system might well be smaller than my C system.
> >
> >Does anyone have any experience of Forth on the Z80 who could comment? How
> >about recommendations on a Forth runtime? I was thinking of using FigForth,
> >as being small, simple and free, but I appreciate it's probably not very
> >highly optimised.
>
> You appear to believe that C is always compiled and that Forth is
> always interpeted.  There are a few C interpeters and a lot of Forth
> compilers.

For the Z80? A Forth compiler?

Just last night I was doing some benchmarking on fibonacci on my TI,
which uses a 3mhz 9900 uP. Perhaps you can do the same - find some
representative code and benchmark it.

Results were (for fib(20)):

3.5 seconds - c99, small C compiler
9   seconds - TI Forth
17  seconds - Wycove Forth

TI Forth did rather well, better than expected, considering it isn't
"speed optimized". c99 isn't optimal, but the best compiler the TI ever
had. I was shocked at Wycove Forth, which is so professionally done,
with good screens of code supporting a lot of options - but almost half
the speed of TI Forth, and not quite 2x faster than UCSD Pascal which
came in at 30 seconds. All of which was faster than TI Logo at 5 mins
30 secs.

Just remember that in Forth once the code is loaded (interpreted) it is
pretty fast, which is why I'm sure it is faster than UCSD (which is
compiled to intermediate p-code which is then interpreted).

Ben

Ben

0
anoneds (102)
6/14/2005 6:44:51 PM
On Tue, 14 Jun 2005 17:17:22 GMT, David Given <dg@cowlark.com> wrote:

>I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
>another language. Normally I'd write this sort of thing in C, except that C
>compilers for the Z80 produce lousy code, in part due to the Z80's design.

What an amazing piece of reverse (inverted?) logic.

C compilers produce lousy code, period.


C language, by design failure, promotes faulty constucts.

The Z-80 is/was a very well thought out design answer to
the need for 8-bit computing. It is still produced, and into
the millions every year. Well, maybe not as a discreet
CPU all the time, sometimes just a gate array.

You really learn the beauty (and forward thinking) that
went into this chip when you learn to program for IT and
NOT within the constraints of some stupid language.

Just as the present generation of CPUs is vastly under
untilized by today's 'language of choice', so also was in
the past. And that's the best reason I could give for why
the Z80 cpu architecture is still 'current'.

It is a very powerful design, with no end-of-life in sight.

Bill

0
Bill3039 (326)
6/14/2005 9:31:21 PM
wild bill wrote:
> On Tue, 14 Jun 2005 17:17:22 GMT, David Given <dg@cowlark.com> wrote:
> 
> 
>>I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
>>another language. Normally I'd write this sort of thing in C, except that C
>>compilers for the Z80 produce lousy code, in part due to the Z80's design.
> 
> 
> What an amazing piece of reverse (inverted?) logic.
> 
> C compilers produce lousy code, period.
> 
> 
> C language, by design failure, promotes faulty constucts.
> 
> The Z-80 is/was a very well thought out design answer to
> the need for 8-bit computing. It is still produced, and into
> the millions every year. Well, maybe not as a discreet
> CPU all the time, sometimes just a gate array.
> 
> You really learn the beauty (and forward thinking) that
> went into this chip when you learn to program for IT and
> NOT within the constraints of some stupid language.
> 
> Just as the present generation of CPUs is vastly under
> untilized by today's 'language of choice', so also was in
> the past. And that's the best reason I could give for why
> the Z80 cpu architecture is still 'current'.
> 
> It is a very powerful design, with no end-of-life in sight.
> 
> Bill
> 

Sooooo, what language ya avocating here ? Assembly ?

0
6/14/2005 10:36:47 PM
"Scott Moore" <samiamsansspam@Sun.COM> wrote in message 
news:d8nm5v$7kb$1@news1nwk.SFbay.Sun.COM...
> wild bill wrote:
>> On Tue, 14 Jun 2005 17:17:22 GMT, David Given <dg@cowlark.com> wrote:
>>
>>
>>>I do *not* want to write this in Z80 assembly; I hate the stuff. So, I 
>>>need
>>>another language. Normally I'd write this sort of thing in C, except that 
>>>C
>>>compilers for the Z80 produce lousy code, in part due to the Z80's 
>>>design.
>>
>>
>> What an amazing piece of reverse (inverted?) logic.
>>
>> C compilers produce lousy code, period.
>>
>>
>> C language, by design failure, promotes faulty constucts.
>>
>> The Z-80 is/was a very well thought out design answer to
>> the need for 8-bit computing. It is still produced, and into
>> the millions every year. Well, maybe not as a discreet
>> CPU all the time, sometimes just a gate array.
>>
>> You really learn the beauty (and forward thinking) that
>> went into this chip when you learn to program for IT and
>> NOT within the constraints of some stupid language.
>>
>> Just as the present generation of CPUs is vastly under
>> untilized by today's 'language of choice', so also was in
>> the past. And that's the best reason I could give for why
>> the Z80 cpu architecture is still 'current'.
>>
>> It is a very powerful design, with no end-of-life in sight.
>>
>> Bill
>>
>
> Sooooo, what language ya avocating here ? Assembly ?


If not him then I do.

Z80 assembly language is clean and easy.


Randy
www.s100-manuals.com 


0
randy38 (638)
6/14/2005 11:14:16 PM
David Given wrote:

(snip)

> I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
> another language. Normally I'd write this sort of thing in C, except that C
> compilers for the Z80 produce lousy code, in part due to the Z80's design.

The only lousy code I know of for C on Z80 is the signed comparison
code.  If you use unsigned variables as much as possible you avoid that.

Of course no multiply and divide doesn't help, but that is probably a
subroutine call.

-- glen

0
gah (12851)
6/15/2005 12:48:10 AM
Randy McLaughlin wrote:
> If not him then I do.
> Z80 assembly language is clean and easy.

It's a small world, but I wouldn't want to paint it.

In other words, I'm happy to write small, easy programs in assembly on a 
Z80.  For anything substantial, I'd just as soon use C or something else 
if I have the memory for it.  Generally, my time is more valuable than a 
few K of memory.

Kelly
0
khall (185)
6/15/2005 1:15:06 AM
"David Given" wrote (among other things):

> I want to write a program for a Z80 platform.

Programming Languages were created to simplify
solving problems in a given field... Hence, business = COBOL,
scientific computations = FORTRAN, etc, etc.
Each PL has its own specialized field.
It all depends on the goal of your program.

> It needs to be efficient and small.

There is only one PL that fits this description:
assembly language. (However, on a Z-80,
don't forget that you can use the 8080
subset, which is simpler and more "orthogonal".)

Yours Sincerely,
"French Luser"



0
Bill.Gates (574)
6/15/2005 9:32:13 AM


French Luser wrote:
>
>"David Given" wrote (among other things):
>
>> I want to write a program for a Z80 platform.
>> It needs to be efficient and small.
>
>There is only one PL that fits this description:
>assembly language.

While it is true in theory that assembly language is more efficient
than C, the code you will get if you hire a good assembly language 
programmer is usually less efficient than the code you will get if 
you hire a good C programmer.

It is a common occurance to replace an assembly language program with
a Forth program and discover that the Forth prrogram is smaller.


0
Guy
6/15/2005 9:37:22 AM
On 2005-06-15, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:
> While it is true in theory that assembly language is more efficient
> than C, the code you will get if you hire a good assembly language 
> programmer is usually less efficient than the code you will get if 
> you hire a good C programmer.

This might be true on modern architectures where the instruction set is rich
and varied with lots of opportunities for serious optimization. I'd be
greatly surprised if it were true on the Z-80. It might be your experience,
but on that machine, I'd say it would speak more about the programmer than
the language.

> It is a common occurance to replace an assembly language program with
> a Forth program and discover that the Forth prrogram is smaller.

Sure. A Forth subroutine call is only two bytes long instead of three, and
in a well-structured program, this adds up.

0
jmaynard (220)
6/15/2005 11:22:19 AM
anoneds@netscape.net wrote:
[...]
> Results were (for fib(20)):
> 
> 3.5 seconds - c99, small C compiler
> 9   seconds - TI Forth
> 17  seconds - Wycove Forth

That's fascinating; c99 and TI Forth are *well* within the same order of
magnitude. TI Forth is a FigForth derivative, isn't it? Do you have a link?
I'd like to have a look at the documentation --- I don't know anything
about the 9900.

-- 
+- David Given --McQ-+ "I love the way Microsoft follows standards. In
|  dg@cowlark.com    | much the same manner that fish follow migrating
| (dg@tao-group.com) | caribou." --- Paul Tomblin
+- www.cowlark.com --+ 

0
dg (326)
6/15/2005 1:59:12 PM
Kelly Hall wrote:
[...]
> In other words, I'm happy to write small, easy programs in assembly on a
> Z80.  For anything substantial, I'd just as soon use C or something else
> if I have the memory for it.  Generally, my time is more valuable than a
> few K of memory.

*nods*

I'm used to orthogonal ISAs like ARM or MCore. The Z80 is so unorthogonal it
makes me faintly nauseous. Which means that writing anything more than tiny
fragments of assembly is well out of the question; I need some other
language to do the bulk of my implementation.

The Z80 has particular trouble with C because C likes to store large
quantities of random-access data on the stack, and the Z80 has a lot of
trouble accessing values that aren't right at the top: you usually end up
having to waste a complete register for use as a frame pointer, and even
then the absence of 16-bit load and store instructions means you need two
instructions for each operation (more if you need offsets that don't fit
into 8 bits).

Forth's access pattern is entirely different: it has two stacks, a return
stack and a data stack. The return stack is strictly only accessible from
the top, and only the top two or three items of the data stack are usually
accessed directly. This means a radically different approach can be taken
which can result in much tighter code

I'm currently looking at a Z80 FigForth I've managed to lay my hands on
(hForth); it's fascinating. The actual threaded code interpreter is about
15 bytes! It uses the Z80's hardware stack for the data stack, and an
IX-based stack for the return stack, which is the exact opposite to what I
would have expected. It stores all the interpreter's state, including the
top data stack item, in registers, which gives it much denser register
usage to the best Z80 C compiler I've seen so far (Hitech C)...

Alas, it's set up as an interactive system, where I want a compiled,
non-interactive system, so I'd need to do some major surgery to use this.
Does anyone have any recommendations of good (free) Z80 Forths?

-- 
+- David Given --McQ-+ "Under communism, man exploits man. Under
|  dg@cowlark.com    | capitalism, it's just the opposite." --- John
| (dg@tao-group.com) | Kenneth Galbrith
+- www.cowlark.com --+ 

1
dg (326)
6/15/2005 2:24:17 PM
"David Given" <dg@cowlark.com> wrote in message 
news:lSWre.13044$K5.1437@newsfe4-win.ntli.net...
> The Z80 has particular trouble with C because C likes to store large
> quantities of random-access data on the stack, and the Z80 has a lot of
> trouble accessing values that aren't right at the top: you usually end up
> having to waste a complete register for use as a frame pointer, and even
> then the absence of 16-bit load and store instructions means you need two
> instructions for each operation (more if you need offsets that don't fit
> into 8 bits).
>
To start, "wasting" a register on a frame pointer (I assume you refer to 
using IX or IY) is an odd way to look at hardware resources.  That's why the 
registers exist.  Yes, the addressing is limited with an index register, but 
Z80s are intended for embedded controller designs, not general purpose 
machines.

As for complaining about 16-bit operations, the Z80 IS an 8-bit CPU. 
Choosing an inappropriate solution and then stating it doesn't meet 
requirements doesn't accomplish much.  Applications which require extensive 
stack manipulations are a poor fit to a Z80, as is using a dual core 3Ghz 
AMD64 with 4GB RAM and 1TB disk to run the lawn sprinkler.

We have a tendency to forget that 8080s and Z80s, although they became 
general purpose computers in the 70s, were never intended to be used for 
that purpose.  Nor was the instruction set ever designed with C as the the 
target language.  Bemoan the lack of instruction set elegance, but it was 
well-suited to an EE writing a small assembler program to control data 
loggers...or lawn sprinklers.
  Jack Peacock 


0
peacock (183)
6/15/2005 2:53:09 PM
David Given wrote:
> The Z80 has particular trouble with C because C likes to store large
> quantities of random-access data on the stack, and the Z80 has a lot of
> trouble accessing values that aren't right at the top: you usually end up
> having to waste a complete register for use as a frame pointer, and even
> then the absence of 16-bit load and store instructions means you need two
> instructions for each operation (more if you need offsets that don't fit
> into 8 bits).

C on the Z80 isn't a big deal - get a compiler that doesn't suck and 
you'll be fine.  I like the Softools product, but be advised that 
professional tools cost money.

If you're running on cp/m you might try Turbo Pascal - I recall it 
generated relatively good code and the price is right these days.

Kelly
0
khall (185)
6/15/2005 3:19:41 PM
David Given wrote:
Does anyone have any recommendations of good (free) Z80 Forths?

As you know there is FIG-FORTH and it's modern ANS compliant
equivalent eForth. There are a number of eForths and eForth
variants including hForth.  TCOM is free target compiling Forth
that as I recall supported an 8080 target, so making it support
Z80 would be a small job.  TCOM compiles native code with peephole
optimization.  It can optionally include a Forth command interpreter
on the target (later version) but doesn't have to include it so you
can generate small stand-alone applications if that is what you want.
There is also CamelForth for Z80. The first Forth I saw was one for
the TRS80 which was of course a Z80 PC.  And there was the Sinclair
and some other very cheap Z80 based computers that ran Forth way
back when.

Best Wishes

0
fox21 (1833)
6/15/2005 4:36:42 PM
"David Given" <dg@cowlark.com> wrote in message 
news:CiEre.23591$iy2.7519@newsfe1-gui.ntli.net...
> I'm posting this here because I suspect that this is one of the few
> newsgroups where people might actually know the answer...
>
> I want to write a program for a Z80 platform. (Potentially running 
> CP/M,
> although that's not terribly relevant.) It needs to be efficient and 
> small.
>
> I do *not* want to write this in Z80 assembly; I hate the stuff. So, I 
> need
> another language. Normally I'd write this sort of thing in C, except 
> that C
> compilers for the Z80 produce lousy code, in part due to the Z80's 
> design.
>
> Would I be better off writing in Forth instead?
>
> Forth will generate threaded code that will need to be interpreted, 
> which
> produces an immediate performance hit. *However*, given that Forth
> interpreters are damned fast, and that the C code we're comparing it 
> with
> is very bad, I think there's a reasonable chance that they'll be 
> within the
> same order of magnitude at least. Plus, Forth code is very dense and 
> my
> Forth system might well be smaller than my C system.
>
> Does anyone have any experience of Forth on the Z80 who could comment? 
> How
> about recommendations on a Forth runtime? I was thinking of using 
> FigForth,
> as being small, simple and free, but I appreciate it's probably not 
> very
> highly optimised.

You say that you want your code to be small and efficient, but you are
willing to give up one order of magnitude in speed to use Forth.  That
sounds to me like size is really the most important to you.

Consider that both C and Forth for the Z80 tend to work with 16 bit
integers (and pointers), where assembly programming often takes 
advantage
of the 8080 & Z80 affinity for byte data.  As a result, the same program
in either C or Forth tends to be larger than an assembly version by a
factor that is very nearly equal to 2.0, with the Forth version only
slightly smaller than the C version.

For size, it can be important to avoid floating point code, including
unused floating point calls in (e.g.) 'printf()'.  The advantage of
Forth is sometimes that it more naturally avoids pulling in unused
support modules.  A little care in your C code's use of subroutines,
and in library linking, can pay off handsomely.

Try looking at Small-C Plus.  The source code for the compiler can be
run through a standard C compiler under PC/MS DOS or *nix to make a
cross-tool.  The library source is also available for when you decide
to go to a non-CP/M target.

I have sometimes considered the possibility of a system I call '8th'.
It would be a version of Forth that uses byte integers to reference
both the most basic operations and the most recently defined operations,
as well as the most common constants.  One of the basic operation codes
would of course be an escape prefix for regular 16 bit codes.  The
interpreter for 8th need not be much bigger or slower than for Forth,
and with a smart Forth-to-8th compiler could achieve nearly 2:1
compression.  Feel free to develop this idea :-). 


0
fjscipio (64)
6/15/2005 4:52:52 PM
Jay Maynard wrote:
> Sure. A Forth subroutine call is only two bytes long instead of three, and
> in a well-structured program, this adds up.

Forth doesn't require a 16-bit threaded code implementation where
Forth words are 16-bit addresses.  It is true that 16-bit threaded code
will be two bytes per Forth word while a 16-bit subroutine threaded
Forth
would be three bytes per word if Z80 subroutine-calls require three
bytes.

But when you go to optimized native code some three byte calls would
be replaced with inlined instructions which might be smaller or faster
than subroutine calls depending on optimizer settings.  Some code will
get cancelled out, some things might go into registers instead of
using the stack.  Some of these things may result in more dense
code yet again than in a 16-bit threaded code implementation.

Then there are token threaded or bit threaded Forths where things
may be smaller yet again. And all tokens don't all have to be the same
size, so many programs can compress to mostly 4-bit tokens or could
even
use something like Huffman encoding of the tokens if a small code
footprint is the goal.

Best Wishes

0
fox21 (1833)
6/15/2005 5:07:52 PM


Jay Maynard wrote:
>
>Guy Macon wrote:
>
>> While it is true in theory that assembly language is more efficient
>> than C, the code you will get if you hire a good assembly language 
>> programmer is usually less efficient than the code you will get if 
>> you hire a good C programmer.
>
>This might be true on modern architectures where the instruction set is rich
>and varied with lots of opportunities for serious optimization. I'd be
>greatly surprised if it were true on the Z-80. It might be your experience,
>but on that machine, I'd say it would speak more about the programmer than
>the language.

You are entirely correct -- even more so when the uP is a 4-bitter.
I think that I misled my own thinking by only considering situations
where I would consider hiring a C programmer... :(






>
>> It is a common occurance to replace an assembly language program with
>> a Forth program and discover that the Forth prrogram is smaller.
>
>Sure. A Forth subroutine call is only two bytes long instead of three, and
>in a well-structured program, this adds up.



0
Guy
6/15/2005 5:35:13 PM
In article <11avtmmnegjjg8c@corp.supernews.com>
           _see.web.page_@_www.guymacon.com_ "Guy Macon" writes:

> French Luser wrote:
> >
> >"David Given" wrote (among other things):
> >
> >> I want to write a program for a Z80 platform.
> >> It needs to be efficient and small.
> >
> >There is only one PL that fits this description:
> >assembly language.

Agreed.

> While it is true in theory that assembly language is more efficient
> than C, the code you will get if you hire a good assembly language 
> programmer is usually less efficient than the code you will get if 
> you hire a good C programmer.

???  You have apparently been hiring the "wrong sort of 
programmer"; a _good_ assembler programmer should beat a _good_ C 
programmer hands down.  And there is no "in theory" bit -- a C 
compiler will always generate overhead that a human assembler can 
avoid.  IMHO of course.

> It is a common occurance to replace an assembly language program with
> a Forth program and discover that the Forth prrogram is smaller.

See above.  Program space in an 8-bit processor is a scarce 
resource, so in a large program a few bytes here, a few bytes 
there, add up.  And the difference between C and ASM can be quite 
dramatic: in order to recover some space in an application that I 
maintain (written mostly in C, no names) I decided to rewrite the 
string handling library (strlen, strcmp, strchr etc.) in ASM to 
replace the C versions.  The resulting linked code is 4K smaller, 
and the performance increase in speed is noticeable.  And I would 
not even describe myself as a _good_ asm programmer.  ASM is as 
close as you will get to the machine code that drives the Z80...

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."
0
pete11 (328)
6/15/2005 5:44:55 PM
"Jack Peacock" <peacock@simconv.com> wrote in message 
news:E7udnXTjl-FL3S3fRVn-vQ@mpowercom.net...
> "David Given" <dg@cowlark.com> wrote in message 
> news:lSWre.13044$K5.1437@newsfe4-win.ntli.net...
>> The Z80 has particular trouble with C because C likes to store large
>> quantities of random-access data on the stack, and the Z80 has a lot of
>> trouble accessing values that aren't right at the top: you usually end up
>> having to waste a complete register for use as a frame pointer, and even
>> then the absence of 16-bit load and store instructions means you need two
>> instructions for each operation (more if you need offsets that don't fit
>> into 8 bits).
>>
> To start, "wasting" a register on a frame pointer (I assume you refer to 
> using IX or IY) is an odd way to look at hardware resources.  That's why 
> the registers exist.  Yes, the addressing is limited with an index 
> register, but Z80s are intended for embedded controller designs, not 
> general purpose machines.
>
> As for complaining about 16-bit operations, the Z80 IS an 8-bit CPU. 
> Choosing an inappropriate solution and then stating it doesn't meet 
> requirements doesn't accomplish much.  Applications which require 
> extensive stack manipulations are a poor fit to a Z80, as is using a dual 
> core 3Ghz AMD64 with 4GB RAM and 1TB disk to run the lawn sprinkler.
>
> We have a tendency to forget that 8080s and Z80s, although they became 
> general purpose computers in the 70s, were never intended to be used for 
> that purpose.  Nor was the instruction set ever designed with C as the the 
> target language.  Bemoan the lack of instruction set elegance, but it was 
> well-suited to an EE writing a small assembler program to control data 
> loggers...or lawn sprinklers.
>  Jack Peacock

No the 8080 and Z80 were designed to be general purpose computers.  The 4004 
was designed as an embedded controller, the potential it showed led to the 
8080.  Intel understood it and that is why they concurrently developed ISIS 
to allow developers to use the 8080 to develop on the 8080.  Before that all 
of Intel's tools were cross support platforms.


Randy
www.s100-manuals.com 


0
randy38 (638)
6/15/2005 6:02:43 PM
Guy Macon wrote:
> French Luser wrote:
> 
>>"David Given" wrote (among other things):
>>
>>
>>>I want to write a program for a Z80 platform.
>>>It needs to be efficient and small.
>>
>>There is only one PL that fits this description:
>>assembly language.
> 
> 
> While it is true in theory that assembly language is more efficient
> than C, the code you will get if you hire a good assembly language 
> programmer is usually less efficient than the code you will get if 
> you hire a good C programmer.
> 
> It is a common occurance to replace an assembly language program with
> a Forth program and discover that the Forth prrogram is smaller.
> 

Forth is threaded from tolkens, which is going to be more compact.
Its also slower (than the equivalent assembly language). You get
what you pay for.

0
6/15/2005 7:45:10 PM
David Given wrote:
> Kelly Hall wrote:
> [...]
> 
>>In other words, I'm happy to write small, easy programs in assembly on a
>>Z80.  For anything substantial, I'd just as soon use C or something else
>>if I have the memory for it.  Generally, my time is more valuable than a
>>few K of memory.
> 
> 
> *nods*
> 
> I'm used to orthogonal ISAs like ARM or MCore. The Z80 is so unorthogonal it
> makes me faintly nauseous. Which means that writing anything more than tiny
> fragments of assembly is well out of the question; I need some other
> language to do the bulk of my implementation.
> 
> The Z80 has particular trouble with C because C likes to store large
> quantities of random-access data on the stack, and the Z80 has a lot of
> trouble accessing values that aren't right at the top: you usually end up
> having to waste a complete register for use as a frame pointer, and even
> then the absence of 16-bit load and store instructions means you need two
> instructions for each operation (more if you need offsets that don't fit
> into 8 bits).

We did this debate some time back. You can fit parameters into registers,
and you can use the ix or iy registers as both a stack frame and a method
of accessing on-frame locals and parameters.

> 
> Forth's access pattern is entirely different: it has two stacks, a return
> stack and a data stack. The return stack is strictly only accessible from
> the top, and only the top two or three items of the data stack are usually
> accessed directly. This means a radically different approach can be taken
> which can result in much tighter code
> 
> I'm currently looking at a Z80 FigForth I've managed to lay my hands on
> (hForth); it's fascinating. The actual threaded code interpreter is about
> 15 bytes! It uses the Z80's hardware stack for the data stack, and an
> IX-based stack for the return stack, which is the exact opposite to what I
> would have expected. It stores all the interpreter's state, including the
> top data stack item, in registers, which gives it much denser register
> usage to the best Z80 C compiler I've seen so far (Hitech C)...
> 
> Alas, it's set up as an interactive system, where I want a compiled,
> non-interactive system, so I'd need to do some major surgery to use this.
> Does anyone have any recommendations of good (free) Z80 Forths?
> 

If you are going to avocate Forth, just do it. Its not necessary to
put down C. They are two different languages for two different applications.

0
6/15/2005 7:48:29 PM

David Given wrote:
> anoneds@netscape.net wrote:
> [...]
> > Results were (for fib(20)):
> >
> > 3.5 seconds - c99, small C compiler
> > 9   seconds - TI Forth
> > 17  seconds - Wycove Forth
>
> That's fascinating; c99 and TI Forth are *well* within the same order of
> magnitude. TI Forth is a FigForth derivative, isn't it? Do you have a link?
> I'd like to have a look at the documentation --- I don't know anything
> about the 9900.

There are several copies of TI Forth on ftp.whtech.com. As for the
documentation, it is separate, and in a TI format under "/9640
news/CAT17". You need to get the ARK files to a TI or emulator disk and
use Archiver 3.01 or above to uncompress. I'm suprised there isn't
another version online. I converted Wycove Forth to Paperport Max
format some time ago.

Yes, they are both FigForth. And I was very impressed by its
performance in relation to c99, which translates small-C to assembler.
I did not run an optimizer (there is a primitive one included with c99)
on the code. The optimizer doesn't do much in past use anyway.

The 9900 is a contemporary of the Z80 of the original poster (in
timeframe, at least) but was the first available 16-bit uP
commercially, available in 1976 IIRC. Had all registers stored in
external RAM with exception of Program Counter, Workspace Pointer (a
pointer to the current 16 16-bit registers) and Status Register. It was
a one-chip implementation of the 990 series of mini-computers from TI,
and looks a lot like a PDP-11 if you look at the instruction set. It is
an enigma, being a 16-bit processor with a 64k address space - a
perfect uP for Forth.

However, c99 isn't a great C compiler. An Ansi C compiler doesn't exist
for the 9900.

Ben

0
anoneds (102)
6/15/2005 9:02:26 PM
On Wed, 15 Jun 2005 11:32:13 +0200, "French Luser"
<Bill.Gates@microsoft.com> wrote:

>
>"David Given" wrote (among other things):
>
>> I want to write a program for a Z80 platform.
>
>Programming Languages were created to simplify
>solving problems in a given field... Hence, business = COBOL,
>scientific computations = FORTRAN, etc, etc.
>Each PL has its own specialized field.
>It all depends on the goal of your program.
>
>> It needs to be efficient and small.
>
>There is only one PL that fits this description:
>assembly language. (However, on a Z-80,
>don't forget that you can use the 8080
>subset, which is simpler and more "orthogonal".)

You have to be kidding!  8080 is more orthogonal than z80..  
NOT IN A PIGS EYE.

The Z80 filled a lot of holes in the 8080 instruction set such 
as 8080 you can load direct the stack pointer register BUT
you cannot store it.  In an 8080 to store the current stack pointer
you clear HL then add SP to HL and then you can save HL.
Z80 has an instruction to store the stackpointer at least.  Thats 
only one example.  But it's the most important one if your doing 
stack oriented work.


Allison

0
nospam74 (614)
6/16/2005 1:07:31 AM
On Wed, 15 Jun 2005 17:44:55 +0000 (UTC), pete@nospam.demon.co.uk
wrote:

>In article <11avtmmnegjjg8c@corp.supernews.com>
>           _see.web.page_@_www.guymacon.com_ "Guy Macon" writes:
>
>> French Luser wrote:
>> >
>> >"David Given" wrote (among other things):
>> >
>> >> I want to write a program for a Z80 platform.
>> >> It needs to be efficient and small.
>> >
>> >There is only one PL that fits this description:
>> >assembly language.
>
>Agreed.
>
>> While it is true in theory that assembly language is more efficient
>> than C, the code you will get if you hire a good assembly language 
>> programmer is usually less efficient than the code you will get if 
>> you hire a good C programmer.
>
>???  You have apparently been hiring the "wrong sort of 
>programmer"; a _good_ assembler programmer should beat a _good_ C 
>programmer hands down.  And there is no "in theory" bit -- a C 
>compiler will always generate overhead that a human assembler can 
>avoid.  IMHO of course.
>
>> It is a common occurance to replace an assembly language program with
>> a Forth program and discover that the Forth prrogram is smaller.
>
>See above.  Program space in an 8-bit processor is a scarce 
>resource, so in a large program a few bytes here, a few bytes 
>there, add up.  And the difference between C and ASM can be quite 
>dramatic: in order to recover some space in an application that I 
>maintain (written mostly in C, no names) I decided to rewrite the 
>string handling library (strlen, strcmp, strchr etc.) in ASM to 
>replace the C versions.  The resulting linked code is 4K smaller, 
>and the performance increase in speed is noticeable.  And I would 
>not even describe myself as a _good_ asm programmer.  ASM is as 
>close as you will get to the machine code that drives the Z80...
>
>Pete

Correct.  However using something like SmallC and some asm you get
a good result.  The problem with C is overhead, same for any language
that is not asm.  The payback for not using asm is maintenance, coding
speed, sometimes a richer tool set.  Most of the C work I've done for
small stuff the overhead is about 1.4 to 1.9 that of straight asm.  If
I do a bit of hybrid coding (asm and C) it can be better but it's a
time, speed and saize trade off.

In engineering there is  Cheap, Fast, Good.  Pick any two.

Allison

0
nospam74 (614)
6/16/2005 1:13:14 AM
fox@ultratechnology.com wrote:
[...]
> TCOM is free target compiling Forth
> that as I recall supported an 8080 target, so making it support
> Z80 would be a small job.

Do you have any references for TCOM? It sounds ideal, apart from the DOS
requirement. None of the links I've found actually work.

> And there was the Sinclair
> and some other very cheap Z80 based computers that ran Forth way
> back when.

I have thought about ripping off the ROM for the Jupiter ACE...

-- 
+- David Given --McQ-+ "I smell a rat; I see him forming in the air &
|  dg@cowlark.com    | darkening the sky; but I'll nip him in the bud."
| (dg@tao-group.com) | --- Sir Boyle Roche
+- www.cowlark.com --+ 

0
dg (326)
6/16/2005 10:22:12 AM
Jack Peacock wrote:
[...]
> To start, "wasting" a register on a frame pointer (I assume you refer to
> using IX or IY) is an odd way to look at hardware resources.  That's why
> the
> registers exist.

The problem I have with this approach is that for code generated by a C
compiler, the frame pointer and the stack pointer are fundamentally the
same thing --- the compiler knows, for every instruction, the offset
between the current value of sp and the stack frame. Having to store the
frame pointer seperately is a waste, because the information is already
there, in the processor's (very scarce) on-chip store.

[...]
> As for complaining about 16-bit operations, the Z80 IS an 8-bit CPU.

Fair enough. The Z80 has enough 16-bit operations that it's tempting to
think of it primarily as a 16-bit processor, which, as you say, it's not.

> Nor was the instruction set ever designed with C as the the
> target language.

Which is a bit of a shame, given that C is the predominant language for
embedded systems these days.

What other reasonably modern programming languages are there for the Z80
(and 8080)?

-- 
+- David Given --McQ-+ "...electrons, nuclei and other particles are good
|  dg@cowlark.com    | approximations to perfectly elastic spherical
| (dg@tao-group.com) | cows." --- David M. Palmer on r.a.sf.c
+- www.cowlark.com --+ 

0
dg (326)
6/16/2005 11:13:59 AM
On 2005-06-16, David Given <dg@cowlark.com> wrote:
> Jack Peacock wrote:
>> Nor was the instruction set ever designed with C as the the
>> target language.
> Which is a bit of a shame, given that C is the predominant language for
> embedded systems these days.

Uhm...the Z-80 was designed in what, 1976? The 8080 it was based on was
designed in what, 1973? When was C designed, and on what system? (Hint: The
PDP-11 ain't an 8080.)

To expect the Z-80 to have been designed with C in mind is just plain silly.
When the Z-80 was designed, assembler was king, and providing a rich set of
features for the assembler programmer was the right choice.

0
jmaynard (220)
6/16/2005 12:24:49 PM
"David Given" <dg@cowlark.com> wrote in message 
news:X9dse.24347$%21.7551@newsfe2-gui.ntli.net...
> The problem I have with this approach is that for code generated by a C
> compiler, the frame pointer and the stack pointer are fundamentally the
> same thing --- the compiler knows, for every instruction, the offset
> between the current value of sp and the stack frame. Having to store the
> frame pointer seperately is a waste, because the information is already
> there, in the processor's (very scarce) on-chip store.
>
Well, no, it's not a waste.  In the Z80 there is no index addressed mode 
using SP, but there is an 8-bit offset address mode using IX/IY.  To compute 
every reference directly from SP takes several instructions, where IX+offset 
takes only one.  Any compiler that generates Z80 specific code can take 
advantage of relative offsets from a base index register, LD A,(IX+offset), 
but I think so many retained 8080 compatibility that they used the LXI 
HL,offset / DAD SP / MOV A,(HL)   method to calculate the effective address 
in the frame.

Even on the x86 there is a separate BP register for the frame.  The problem 
with using SP as the base address is that it complicates other stack uses, 
like evaluating arithmetic expressions which push intermediate results on 
the stack.  Sure there are ways to program around it, but just using a 
separate frame pointer is much easier to implement.
  Jack Peacock 


0
peacock (183)
6/16/2005 2:36:19 PM
David Given originally posted that he was interested in using Forth on
a Z80 and not so interested in using C, because of size and (his claim)
poor "efficiency" for C on Z80s. But most of the thread discussion has
been about C. Speaking strictly for myself, I'd like to see more
*Forth* discussion, if only for variety but also for good information.

There have been a number of "C" discussions in comp.os.cpm recently,
and over the years as it turns out; but not too many discussions about
Forth. There have also been discussions about how the Z80 supports
languages like C, but again not much about supporting Forth. The
exchange below is kinda typical of those other, prior discussions:

David Given wrote:
> Jack Peacock wrote:
> [...]
> > To start, "wasting" a register on a frame pointer (I assume you refer to
> > using IX or IY) is an odd way to look at hardware resources.  That's why
> > the registers exist.
>
> The problem I have with this approach is that for code generated by a C
> compiler, the frame pointer and the stack pointer are fundamentally the
> same thing --- the compiler knows, for every instruction, the offset
> between the current value of sp and the stack frame. Having to store the
> frame pointer seperately is a waste, because the information is already
> there, in the processor's (very scarce) on-chip store.
>
> [...]
> > As for complaining about 16-bit operations, the Z80 IS an 8-bit CPU.
>
> Fair enough. The Z80 has enough 16-bit operations that it's tempting to
> think of it primarily as a 16-bit processor, which, as you say, it's not.
>
> > Nor was the instruction set ever designed with C as the the
> > target language.
>
> Which is a bit of a shame, given that C is the predominant language for
> embedded systems these days.
>
> What other reasonably modern programming languages are there for the Z80
> (and 8080)?
>
> +- David Given

To answer David's questions on C and on other languages, and even on
efficiency, I'd reference him first to those prior discussions I
mentioned. Try these threads in comp.os.cpm, which I found with a bit
of time and Google:

"Inefficient C Language" - May 17th 2005, over 45 replies
"Compiled languages for the Z80" - Feb 17 2004, 108 messages
"Programming for CP/M-86" etc. - Dec 14 2003, 10 msgs
"ZSM 2.8 assembler" - Oct 23 2003, 29 msgs
"C vs. Assembler" and  "C - learning curve" - Jan 1 2002, about 100 msg
                                            -  but meandering

Why talk again about stuff when prior threads are readily available?
(Again, just my opinion and reaction.)

Since I asked, I'll offer some *Forth* discussion points. It may be
that there were not too many Forth discussions, or Z80 Forth
implementations, because 1) Forth was more popular a few decades ago;
2) early Forth implementations are pretty adequate today, as of course
Forth is naturally extensible and 3) Forth is counter to the trend of
"higher" level languages. Maybe 4) Forth Inc. provided a commercial
standard implementation early on, so there were not too many
competitors. I can't recall offhand more than four or five "forth"'s.

But Forth is quite useful where *total* code space is minimal; where
you need development flexibility; and where the task is more "nuts and
bolts" operations than human interface and GUI. (Good examples: bootROM
code, on-board hard drive code.) All of this is of course arguable, and
language choices tend to be personal rather than technological. Since
David Given has not said what his program MUST DO, other than be small,
"efficient", and on a Z80, the discussion is not driven by
requirements. FIGForth is small, tweaks may make it more efficient but
I'd first ask "efficient to do WHAT?".

So, if the thread is going to meander between language favorites and
details of language impementations, the thread may as well focus on
Forth, because "C", and even assembler, has had plenty of prior chat
(in my opinion).

Herb Johnson

Herbert R. Johnson, voice 609-771-1503, New Jersey USA
<a href="http://njcc.com/~hjohnson"> my web site</a>
<a href="http://retrotechnology.com/herbs_stuff"> web site mirror</a>
<a href="http://retrotechnology.net/herbs_stuff"> domain mirror</a>
my email address: herbjohnson ATT comcast DOTT net
wait a day and if that fails, try: hjohnson AAT retrotechnology DOTT
com
good used Mac, SGI, 8-inch floppy drives
S-100 IMSAI Altair computers, docs, by "Dr. S-100"

0
noone1 (119)
6/16/2005 3:02:53 PM
David Given wrote:
> Do you have any references for TCOM? It sounds ideal,
> apart from the DOS requirement. None of the links I've
> found actually work.

You should be able to get a copy from www.forth.org
in the compiler section.  There are some other places
on the web where you should be able to get it, but
fig should have it.

Yes, it runs under DOS and can produce 8086 .com files
that are very small.  I have not used it to produce
targets for other processors so I don't know how much
work will be involved it getting it to gen CPM executables.
But it is free.

Best Wishes

0
fox21 (1833)
6/16/2005 3:37:02 PM


pete@nospam.demon.co.uk wrote:

>> While it is true in theory that assembly language is more efficient
>> than C, the code you will get if you hire a good assembly language 
>> programmer is usually less efficient than the code you will get if 
>> you hire a good C programmer.
>
>???  You have apparently been hiring the "wrong sort of 
>programmer"; a _good_ assembler programmer should beat a _good_ C 
>programmer hands down.  And there is no "in theory" bit -- a C 
>compiler will always generate overhead that a human assembler can 
>avoid.  IMHO of course.

This assumes that the assembler programmer can sit down and write 
code that is as efficient as the code that the C compiler calls
from libraries and that you can hand-optimize better than the 
compiler can machine optimize.  That's a dubious proposition if
there are a lot of library calls and the libraries in question 
have had a team optimizing them and refining them for a long 
period  of time.  Hand-optimizing better than the compiler can 
machine optimize is easier to do, but becomes more and more 
difficult as the size and complexity of the program increases.

I should expand on the above and say that it becomes less and less
likely that the code you will get if you hire a good assembly language 
programmer is less efficient than the code you will get if you hire 
a good C programmer as the problem gets simpler and the processor
gets smaller / less capable.  A good assembler programmer will not
beat a good C programmer hands down on a very large and complex 
program but will smoke him on a tiny one. In theory he could win on
the large program in practice he won't be able to pull it off and he 
may not even be able to finish the program.


0
Guy
6/16/2005 3:46:12 PM
Herb Johnson wrote:
> David Given originally posted that he was interested in using Forth on
> a Z80 and not so interested in using C, because of size and (his claim)
> poor "efficiency" for C on Z80s. But most of the thread discussion has
> been about C. Speaking strictly for myself, I'd like to see more
> *Forth* discussion, if only for variety but also for good information.

Indeed. (This is partially my fault; I do tend to get sidetracked easily...)

Has anyone here had any experience of programming in Forth for the Z80 or
8080, whether or CP/M or otherwise? Is it a good match?

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | "All power corrupts, but we need electricity." ---
| (dg@tao-group.com) | Diana Wynne Jones, _Archer's Goon_
+- www.cowlark.com --+ 

0
dg (326)
6/16/2005 5:15:54 PM
On Thu, 16 Jun 2005 11:13:59 GMT
David Given <dg@cowlark.com> wrote:

> Which is a bit of a shame, given that C is the predominant language
> for embedded systems these days.

Unfortunately (that C is predominant, that is)

> What other reasonably modern programming languages are there for the
> Z80 (and 8080)?

Try Modula-2 for a reasonably modern language.  A CP/M version for Z80s
(Compiler, linker, libraries, sample source) is on my web page at:

	http://home.att.net/~halbower/

Hal
0
6/16/2005 6:50:33 PM
"David Given" <dg@cowlark.com> wrote in message
news:etise.25882$iy2.528@newsfe1-gui.ntli.net...
> Has anyone here had any experience of programming in Forth for the Z80
> or 8080, whether or CP/M or otherwise? Is it a good match?

I did some work on a Z80 @ 4MHz with (as I recall) 8K of ROM (contained the
FORTH core and floppy loader), 32K of RAM and a floppy for save/load of the
FORTH programs.  I was mostly helping someone else debug a hardware problem.

One thing notable about using the machine was that this guy was fast with it.
About the time I'd explain what I wanted him to try, he had it ready to go.  And
some of these operations weren't anything like simple.  We were dealing with a
graphics system (putting mechanical diagrams on a CRT), and I never noticed any
more of a delay from it than from our shipping product, which was DG Nova based
and used a fair amount of assembler but a great deal of FORTRAN and TPL. Perhaps
important was that the shipping product did everything relative to the job,
whereas the FORTH gadget was just the display part.  The plan was to use it to
offload a portion of the graphical presentation work from the main system.

Ultimately, didn't work out, I'm thinking it wasn't enough cheaper or faster
than the production system, but I'm not sure I'm remembering that correctly.

    - Bill


0
Bill_Leary (360)
6/16/2005 10:40:07 PM
From: "Guy Macon" <_see.web.page_@_www.guymacon.com_>
Sent: Thursday, June 16, 2005 10:46 AM

> pete@nospam.demon.co.uk wrote:
>
>>> While it is true in theory that assembly language is more efficient
>>> than C, the code you will get if you hire a good assembly language
>>> programmer is usually less efficient than the code you will get if
>>> you hire a good C programmer.
>>
>>???  You have apparently been hiring the "wrong sort of
>>programmer"; a _good_ assembler programmer should beat a _good_ C
>>programmer hands down.  And there is no "in theory" bit -- a C
>>compiler will always generate overhead that a human assembler can
>>avoid.  IMHO of course.
>
> This assumes that the assembler programmer can sit down and write
> code that is as efficient as the code that the C compiler calls
> from libraries and that you can hand-optimize better than the
> compiler can machine optimize.  That's a dubious proposition if
> there are a lot of library calls and the libraries in question
> have had a team optimizing them and refining them for a long
> period  of time.  Hand-optimizing better than the compiler can
> machine optimize is easier to do, but becomes more and more
> difficult as the size and complexity of the program increases.
>
> I should expand on the above and say that it becomes less and less
> likely that the code you will get if you hire a good assembly language
> programmer is less efficient than the code you will get if you hire
> a good C programmer as the problem gets simpler and the processor
> gets smaller / less capable.  A good assembler programmer will not
> beat a good C programmer hands down on a very large and complex
> program but will smoke him on a tiny one. In theory he could win on
> the large program in practice he won't be able to pull it off and he
> may not even be able to finish the program.

A good assembler programmer will always write more efficient code that C 
programmers.

As programs get larger the efficiency rate of Assembler programs go up, C 
stays constant.

Percentage wise the overhead of C makes it appear to become more efficient 
but after discounting the overhead the compiler will still follow its fixed 
optimization while the Assembly language programmer gains more opportunities 
to optimize.

A short while back there was someone asking us to do his homework of 
swapping the data from two adjacent bytes.  We made a game to see how few 
instructions it would take for an 8085, my answer was three instructions 
long.  It was ugly but it performed the task in a way no compiler ever 
would.  For "efficiency" it was truly optimized I understood the rule and 
wrote code to do it.


Randy
www.s100-manuals.com 


0
randy38 (638)
6/16/2005 10:46:34 PM
Hi Randy
 That is not completely true. The SIM4-02 had a built in
assembler as well as did the MOD8 ( 8008 ) machines.
Still, any high level language development was done
from a cross platform. Almost all applications were
done cross platform as well as assembly code. One could
still enter their program on a teletype and create a
paper tape to load into one of the early development
systems that used the target processor.
Dwight


Randy McLaughlin wrote:
---snip---
>
> No the 8080 and Z80 were designed to be general purpose computers.  The 4004
> was designed as an embedded controller, the potential it showed led to the
> 8080.  Intel understood it and that is why they concurrently developed ISIS
> to allow developers to use the 8080 to develop on the 8080.  Before that all
> of Intel's tools were cross support platforms.
> 
> 
> Randy
> www.s100-manuals.com

0
dkelvey (274)
6/17/2005 12:16:44 AM
Hi
 I've implemented a basic FIG Forth on both an 8080 and
Z80 platform ( years ago ). I didn't use a Forth specifically
for the Z80. FIG is in public domain and so available
as an example. Implementing it just includes a console in/out
and a disk interface. To bring it up from scratch, one can
just do the console in/out to start. This way one can use
the interactive nature of Forth to get the disk interface
working.
 There are other Forths that run on the Z80. Some are native
code compilers as well. Not all Forths need to be token
or address interpreters. I like Forth a lot but I would have
to admit that on most benchmarks, C will equal or beat the
fastest Forth. This has more to do with how the typical processor
works than what the potential of the language is. As an example,
I wrote code that would sort 1000 integers in 19.2 uS on a
4 MHz NC4000. Try that on what you're using today and scale to 4 MHz.
 One thing that I have found in the past is that complete applications
often run faster than similar application written in things
like C. You might ask why that is when C creates faster code.
It is mostly because in Forth, you modify Forth to become the
application while in other languages like C, the language hampers
your thinking about the problem set. One tends to worry more
about just getting it to work than understanding what would
be the best solution for the problem.
Just my thoughts
Dwight


David Given wrote:
> Herb Johnson wrote:
> > David Given originally posted that he was interested in using Forth on
> > a Z80 and not so interested in using C, because of size and (his claim)
> > poor "efficiency" for C on Z80s. But most of the thread discussion has
> > been about C. Speaking strictly for myself, I'd like to see more
> > *Forth* discussion, if only for variety but also for good information.
>
> Indeed. (This is partially my fault; I do tend to get sidetracked easily...)
>
> Has anyone here had any experience of programming in Forth for the Z80 or
> 8080, whether or CP/M or otherwise? Is it a good match?
>
> --
> +- David Given --McQ-+
> |  dg@cowlark.com    | "All power corrupts, but we need electricity." ---
> | (dg@tao-group.com) | Diana Wynne Jones, _Archer's Goon_
> +- www.cowlark.com --+

0
dkelvey (274)
6/17/2005 12:33:24 AM
Randy McLaughlin wrote:

> A good assembler programmer will always write more efficient code that C 
> programmers.

Reality: On small processors like the Z80, the compilers suck toliet water.
Drawing any conclusions about compilers on a Z80 is like drawing conclusions
on the Effel tower based on a lug nut.

> 
> As programs get larger the efficiency rate of Assembler programs go up, C 
> stays constant.

As programs get larger, programmers have less time to carefully examine each
small section of code, and the likely hood that a high optimization compiler
will do better than them goes up dramatically.

> 
> Percentage wise the overhead of C makes it appear to become more efficient 
> but after discounting the overhead the compiler will still follow its fixed 
> optimization while the Assembly language programmer gains more opportunities 
> to optimize.

C compilers *appear* to have overhead because the ones you have been using
suck. See answer one.

Question: do you have to have a frame pointer in C ?

Answer: no, its quite possible for the compiler to eliminate the frame if
it doesent need it, and on most routines (1, 2 or 3 parameters and small
locals) it dosen't.

Question: Are assembly language programmers better on the Z80 because they
can use byte registers ?

Answer: no. Compilers can do that as well, PROVIDED the programmer using
the compiler only specifies the exact data length needed. If a lazy programmer
specifies everything to be INT, she/he is screwed. End of story.

Question: Aren't I clever because I can pack all my parameters in registers
and not use stack frames.

Answer: compilers have been performing this stupid pet trick since Jesus
walked. Get over yourself.

> 
> A short while back there was someone asking us to do his homework of 
> swapping the data from two adjacent bytes.  We made a game to see how few 
> instructions it would take for an 8085, my answer was three instructions 
> long.  It was ugly but it performed the task in a way no compiler ever 
> would.  For "efficiency" it was truly optimized I understood the rule and 
> wrote code to do it.
> 

Ha ha. A compiler only applies the rules the compiler maker gives it. You
are probally talking about the xor swap trick. My, aren't we clever.
A compiler can just as easily use that trick. In fact, the compiler can
remember a lot more tricks than you can.

This message brought to you by Attitude Man (TM)

Hey, the tread was getting boring.....

0
6/17/2005 1:07:10 AM
On 2005-06-17, dkelvey@hotmail.com <dkelvey@hotmail.com> wrote:
>  I've implemented a basic FIG Forth on both an 8080 and
> Z80 platform ( years ago ). I didn't use a Forth specifically
> for the Z80. FIG is in public domain and so available
> as an example. Implementing it just includes a console in/out
> and a disk interface. To bring it up from scratch, one can
> just do the console in/out to start. This way one can use
> the interactive nature of Forth to get the disk interface
> working.

Uhm...don't you also have to code the inner interpreter and a few other
primitives, if you're porting it to a new architecture?
0
jmaynard (220)
6/17/2005 1:19:30 AM
Randy McLaughlin wrote:
> A good assembler programmer will always write more efficient code that C 
> programmers.

Depending on the compiler and architecture.  For crappy compilers and 
old ugly architectures (combined, this applied directly to CP/M on Z80s) 
you can probably reap great performance gains rewriting parts of your 
system in assembly.

For people who positively, absolutely want tight code but don't care to 
write it themselves, check out the GNU SuperOptimizer: 
http://www.idiom.com/free-compilers/TOOL/C-8.html

But the real question is what about the efficiency of the code writers 
and maintainers?  I can crank out C code a lot faster than I can write 
in assembler.  If I need to hire more people, I can hire people that are 
fluent in C for a lot less money than people that are fluent in 
assembler.  And I'd much rather port C code than assembler if I end up 
changing hardware down the road.

There's no conspiracy to get rid of assembler programming and assembler 
programmers.  But there are strong economic reasons to explain why it's 
not particularly common any more.

Kelly
0
khall (185)
6/17/2005 1:42:37 AM
On 2005-06-17, Kelly Hall <khall@acm.org> wrote:
> If I need to hire more people, I can hire people that are fluent in C for
> a lot less money than people that are fluent in assembler.

Just becaue someone's fluent in C doesn't mean they'll do well at writing
code that needs to be small and fast, or that they'll do well in an embedded
environment. Lots of companies migrate to C for those kinds of things
thinking they'll hire some IROC for cheap and discover they're wasting their
money.

0
jmaynard (220)
6/17/2005 2:29:45 AM
Kelly Hall wrote:
> 
.... snip ...
> 
> There's no conspiracy to get rid of assembler programming and
> assembler programmers.  But there are strong economic reasons to
> explain why it's not particularly common any more.

In the few places where the abilities are needed, it is usually
cheaper to buy faster hardware.  That leaves code generators for
compilers, and Mars landers as the primary assembly language
fields.  Well, some drivers too.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

0
cbfalconer (19194)
6/17/2005 6:04:01 AM
Jay Maynard wrote:
> Just becaue someone's fluent in C doesn't mean they'll do well at writing
> code that needs to be small and fast, or that they'll do well in an embedded
> environment.

Who claimed otherwise?

> Lots of companies migrate to C for those kinds of things
> thinking they'll hire some IROC for cheap and discover they're wasting their
> money.

C certainly isn't for all applications.  But time marches on, and with 
it transistors become cheaper and cheaper.  So more and more engineers 
will opt to use processors with more memory, trading the inefficiencies 
of C for faster development time, lower maintenance costs, and the 
fleeting chance of portability.

One of my friends finished a small controller with a ColdFire on it, 
where the bulk of the application code was written in UML and compiled 
down to C and finally made into an executable.  This board replaces an 
8051 and some assembly.  This apparently makes economic sense for the 
company involved even though the new hardware is much more pricey than 
the old.

There are folks using Java for embedded applications, you know ;) I 
subscribe to the mailing lists just to see how they're doing.  I don't 
think it's prime time yet, but over time hardware costs will drop to the 
point it might be the obvious way to go for typical projects.

Kelly
0
khall (185)
6/17/2005 7:27:47 AM

Kewpy wrote:
> "David Given" <dg@cowlark.com> sez...
> >
> >I'm posting this here because I suspect that this is one of the few
> >newsgroups where people might actually know the answer...
> >
> >I want to write a program for a Z80 platform. (Potentially running CP/M,
> >although that's not terribly relevant.) It needs to be efficient and small.
> >
> >I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
> >another language. Normally I'd write this sort of thing in C, except that C
> >compilers for the Z80 produce lousy code, in part due to the Z80's design.
> >
> >Would I be better off writing in Forth instead?
> >
> >Forth will generate threaded code that will need to be interpreted, which
> >produces an immediate performance hit. *However*, given that Forth
> >interpreters are damned fast, and that the C code we're comparing it with
> >is very bad, I think there's a reasonable chance that they'll be within the
> >same order of magnitude at least. Plus, Forth code is very dense and my
> >Forth system might well be smaller than my C system.
> >
> >Does anyone have any experience of Forth on the Z80 who could comment? How
> >about recommendations on a Forth runtime? I was thinking of using FigForth,
> >as being small, simple and free, but I appreciate it's probably not very
> >highly optimised.
>
> You appear to believe that C is always compiled and that Forth is
> always interpeted.  There are a few C interpeters and a lot of Forth
> compilers.

bj: I want to comment on the FORTH assembler. I too would not want to
write an entire application in assembler, but I find it particularly
easy to write words with the FORTH assembler. It provides structured
loops and conditionals.
It is very easy to modularize and call from hi-level routines. And very
easy to test using the regular DOS debugger. (My original machine was
an 8080 with the original MITS copyright on the S100 system boards. But
I don't remember what CP/M provided anymore. All I remember is doing
applications in dBASE, and moving a book publishing system from a
CP/M machine to an IBM-XT. It was before font-creation software was
available
so I had to create the fonts by hand with DEBUG. Then I learned about
FORTH.)

bj: Anyway, I recommend you find a "native" code FORTH, such as
Elizabeth Rather mentions in her response to me (see the F83 thread).
That should improve the performance over FIG and F83, and other
indirectly threaded and directly threaded FORTHs. Then you can easily
improve the performance further with assembler words written with the
FORTH assembler. (I have been dabbling with direct assembler calls to
the BIOS, avoiding the calls of F83 through
DOS, and find it satisfying that it is so easy to mix hi-leve FORTH
with
simple assembler calls.)

Bob Jaffray

0
bobjaffray (201)
6/17/2005 4:13:49 PM
"David Given" <d...@cowlark.com> sez...

  ...

>Forth will generate threaded code that will need to be interpreted, which
>produces an immediate performance hit. *However*, given that Forth
>interpreters are damned fast, and that the C code we're comparing it with
>is very bad, I think there's a reasonable chance that they'll be within the
>same order of magnitude at least. Plus, Forth code is very dense and my
>Forth system might well be smaller than my C system.

sizeof(Forth) = sizeof(C)/2 wouldn't surprise me. By the time all the
source is loaded, Forth is compiled. This isn't the place to write a
tutorial on Forth's "under the hood" working, but one is available if
you want.

>Does anyone have any experience of Forth on the Z80 who could comment? How
>about recommendations on a Forth runtime? I was thinking of using FigForth,
>as being small, simple and free, but I appreciate it's probably not very
>highly optimised.

I did some good professional work with Forth on the Z80, both "bare
iron" and under CP/M. I have two versions. The last one I used and
therefore the most highly extended to my needs, is PolyFORTH, and
proprietary. The earlier one, AForth, was abandoned and while not
formally in the public domain, has no one to claim it. I still have it
on disk and the manual,. If you can do no better, email me in a week or
so, when I'll be home again.

Jerry

P.S. I don't see Given's original post on Google, so I'm responding one
branch down.

0
jya (12871)
6/17/2005 9:29:02 PM
Hi
 Correction:
   That should read 19.2 mS to sort 1000 16 bit integers, not
 19.2 uS. Getting a little brain fade.
Dwight

dkelvey@hotmail.com wrote:
> Hi
>  I've implemented a basic FIG Forth on both an 8080 and
> Z80 platform ( years ago ). I didn't use a Forth specifically
> for the Z80. FIG is in public domain and so available
> as an example. Implementing it just includes a console in/out
> and a disk interface. To bring it up from scratch, one can
> just do the console in/out to start. This way one can use
> the interactive nature of Forth to get the disk interface
> working.
>  There are other Forths that run on the Z80. Some are native
> code compilers as well. Not all Forths need to be token
> or address interpreters. I like Forth a lot but I would have
> to admit that on most benchmarks, C will equal or beat the
> fastest Forth. This has more to do with how the typical processor
> works than what the potential of the language is. As an example,
> I wrote code that would sort 1000 integers in 19.2 uS on a
> 4 MHz NC4000. Try that on what you're using today and scale to 4 MHz.
>  One thing that I have found in the past is that complete applications
> often run faster than similar application written in things
> like C. You might ask why that is when C creates faster code.
> It is mostly because in Forth, you modify Forth to become the
> application while in other languages like C, the language hampers
> your thinking about the problem set. One tends to worry more
> about just getting it to work than understanding what would
> be the best solution for the problem.
> Just my thoughts
> Dwight
>
>
> David Given wrote:
> > Herb Johnson wrote:
> > > David Given originally posted that he was interested in using Forth on
> > > a Z80 and not so interested in using C, because of size and (his claim)
> > > poor "efficiency" for C on Z80s. But most of the thread discussion has
> > > been about C. Speaking strictly for myself, I'd like to see more
> > > *Forth* discussion, if only for variety but also for good information.
> >
> > Indeed. (This is partially my fault; I do tend to get sidetracked easily...)
> >
> > Has anyone here had any experience of programming in Forth for the Z80 or
> > 8080, whether or CP/M or otherwise? Is it a good match?
> >
> > --
> > +- David Given --McQ-+
> > |  dg@cowlark.com    | "All power corrupts, but we need electricity." ---
> > | (dg@tao-group.com) | Diana Wynne Jones, _Archer's Goon_
> > +- www.cowlark.com --+

0
dkelvey (274)
6/17/2005 11:56:58 PM
David Given wrote:
> Kelly Hall wrote:
> [...]
> 
>>In other words, I'm happy to write small, easy programs in assembly on a
>>Z80.  For anything substantial, I'd just as soon use C or something else
>>if I have the memory for it.  Generally, my time is more valuable than a
>>few K of memory.
> 
> 
> *nods*
> 
> I'm used to orthogonal ISAs like ARM or MCore. The Z80 is so unorthogonal it
> makes me faintly nauseous. Which means that writing anything more than tiny
> fragments of assembly is well out of the question; I need some other
> language to do the bulk of my implementation.

With all due respect to your delicate condition, the unorthogonality of 
the Z80 has not prevented it from being one of the most-used CPUs of all 
time. In fact, one might argue that it made possible such wide use, as 
it made possible a smaller die than would have been needed for a 
similarly powerful ortoganl machine.

Bill
0
wmeyer (59)
6/18/2005 12:50:46 AM
David Given wrote:
> 
> Which is a bit of a shame, given that C is the predominant language for
> embedded systems these days.

The Z80 was designed at a time when the conventional wisdom held 
(without any justification, btw) that an 8-bit architecture was unsuited 
to compiled code, and even if such a (cross-)compiler could be produced, 
the 8-bit machines most certainly could not host a competent compiler.

So much for "wisdom". I presume that those pundits never read David 
Gries, nor seriously studied even the state as it was then of compiler 
design. Gries describes one compiler (which ran on 4K-words of storage, 
IIRC) that ran 63 passes. It's not the compiler that fails, but the wit 
of its designer.

Anyway, I am sure there must be compilers available these days that 
produce competent object for a Z80 compiler. If not, perhaps you should 
take a look at the Rabbit 3000, as there are certainly C compilers for 
that, and from what I have heard, they generate quite good code.

Bill

Bill
0
wmeyer (59)
6/18/2005 12:57:03 AM
Jay Maynard wrote:
> 
> Uhm...don't you also have to code the inner interpreter and a few other
> primitives, if you're porting it to a new architecture?

Apparently you're showing your age with that question. I'm told that the 
  interpreter is a thing of the past, and that modern Forth's compile 
their code. Makes me wonder then, why Forth? Unless you really like that 
syntax...

Bill
0
wmeyer (59)
6/18/2005 1:07:34 AM
William Meyer wrote:
> Anyway, I am sure there must be compilers available these days that 
> produce competent object for a Z80 compiler. If not, perhaps you should 
> take a look at the Rabbit 3000, as there are certainly C compilers for 
> that, and from what I have heard, they generate quite good code.

Softools generates good code for the Rabbit.  Softools also offers Z80 
and Z180 compilers.

Dynamic C generates so-so code, but has some nice hand-crafted 
libraries.  Dynamic C only supports the Rabbit, but you might be able to 
find legacy versions that support the Z180.  Be advised the Dynamic C is 
not ANSI C, and is not designed to produce code for hardware that 
doesn't come from ZWorld.

The ez80 from Zilog has a free/cheap C compiler available.

Kelly
0
khall (185)
6/18/2005 2:16:15 AM
Kelly Hall wrote:
> William Meyer wrote:
> 
>> Anyway, I am sure there must be compilers available these days that 
>> produce competent object for a Z80 compiler. If not, perhaps you 
>> should take a look at the Rabbit 3000, as there are certainly C 
>> compilers for that, and from what I have heard, they generate quite 
>> good code.
> 
> 
> Softools generates good code for the Rabbit.  Softools also offers Z80 
> and Z180 compilers.

Yes, I know of that one, but haven't used it.

> Dynamic C generates so-so code, but has some nice hand-crafted 
> libraries. 

Also nice is that in the nature of that tool, you get the source to the 
libraries, always a plus.

> Dynamic C only supports the Rabbit, but you might be able to 
> find legacy versions that support the Z180.  Be advised the Dynamic C is 
> not ANSI C, and is not designed to produce code for hardware that 
> doesn't come from ZWorld.

Yes, it is different than ANSI C, but that's not always a concern, and 
for someone considering Forth, I'd imagine correspondence to ANSI C 
might be a very low priority.

> The ez80 from Zilog has a free/cheap C compiler available.

But I observe you make no comment on the quality of that tool.

Bill
0
wmeyer (59)
6/18/2005 3:17:47 AM
"William Meyer" <wmeyer@sbcglobal.net> wrote in message 
news:vnMse.4143$Pa5.793@newssvr21.news.prodigy.com...
> Kelly Hall wrote:
<snip>
>> The ez80 from Zilog has a free/cheap C compiler available.
>
> But I observe you make no comment on the quality of that tool.
>
> Bill

I find it OK but I rarely use it, I much prefer the assembler which is a 
good one.

I doubt the C compiler will generate Z80/Z180 code.

There are many good C compilers for the Z80 both CP/M and cross compilers 
but there are even better assemblers :)

You can check out HighTec and SDCC.


Randy
www.s100-manuals.com 


0
randy38 (638)
6/18/2005 3:47:26 AM
On Fri, 17 Jun 2005 14:29:02 -0700, jya@ieee.org wrote
(in article <1119043742.932693.194080@z14g2000cwz.googlegroups.com>):

> sizeof(Forth) = sizeof(C)/2 wouldn't surprise me. By the time all the
> source is loaded, Forth is compiled. This isn't the place to write a
> tutorial on Forth's "under the hood" working, but one is available if
> you want.

I did quite a bit of Z80 (Oh, that makes me cringe) work 1997 to 2000. The C 
from ZWorld - Dynamic C - has some funny ways, but Hello World compiled to 
less than 100 bytes with init code and the works. At the same time we bought 
MPE's target compiler for Z80 and had to abandon it due to trouble shooting 
difficulties and limitations on what we could run and when. I don't know what 
the MPE products are like today but it looks like there has been a lot of 
improvement. Anyway, if I had a native Z80 Forth at the time I would have 
built a special motherboard for the embedded system so that I could work 
interactively without the limitations of the metacompiler-target-debugger 
connection, provided I could compile for a ROM application. I would have been 
a lot happier, fit more code into the project, and made changes a lot 
quicker.

I also looked at Forth Inc. but by then the powers in charge didn't want any 
more changes. Probably should have bought it in the first place. Actually, 
should have pushed harder to redesign with an ARM instead of settling for a 
faster (shudder) Z80.

-- Charlie Springer

0
RAM6246 (431)
6/18/2005 4:47:39 AM
William Meyer wrote:
> Also nice is that in the nature of that tool, you get the source to the 
> libraries, always a plus.

Heh - that's a nice way of putting it.  A different way of putting is 
that Dynamic C doesn't support linking object files, and thus recompiles 
the libraries from scratch every time you press F9.

I'm all for source code with the libraries, but it really sucks to give 
up the linker.  Also note that ZWorld offers a library encryption 
package so that people can distribute their libraries but not let people 
look at them.

The lack of a linker might have been a great trade off (compiling and 
download speed versus ZWorld's convenience) back when their hardware had 
32K or 64K of program storage.  Now the boards can have 512K and 
compiling and downloading that over a serial cable sucks.  A linker 
would save the extra time to compile the libraries, and a dynamic linker 
would save the download time.  But I digress...

> Yes, it is different than ANSI C, but that's not always a concern, and 
> for someone considering Forth, I'd imagine correspondence to ANSI C 
> might be a very low priority.

True.  One rarely hears about people trying to port someone else's Forth 
code to their application.  But one of the great advantages of C is that 
there is a lot of useful code out there.  Dynamic C makes reusing other 
people's ANSI C code more difficult, but it's not quite in the ballpark 
of Forth (yet).

>> The ez80 from Zilog has a free/cheap C compiler available.
> But I observe you make no comment on the quality of that tool.

I've got the ez80 eval kit on my shelf, but haven't spent any time with 
it.

Kelly
0
khall (185)
6/18/2005 5:42:39 AM
In article <11au5p2h7c1vndb@corp.supernews.com>,
Kewpy  <nospam@nospam.com> wrote:
>
>
>
>"David Given" <dg@cowlark.com> sez...
>>
>>I'm posting this here because I suspect that this is one of the few
>>newsgroups where people might actually know the answer...
>>
>>I want to write a program for a Z80 platform. (Potentially running CP/M,
>>although that's not terribly relevant.) It needs to be efficient and small.
>>
>>I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
>>another language. Normally I'd write this sort of thing in C, except that C
>>compilers for the Z80 produce lousy code, in part due to the Z80's design.
>>
>>Would I be better off writing in Forth instead?
>>
>>Forth will generate threaded code that will need to be interpreted, which
>>produces an immediate performance hit. *However*, given that Forth
>>interpreters are damned fast, and that the C code we're comparing it with
>>is very bad, I think there's a reasonable chance that they'll be within the
>>same order of magnitude at least. Plus, Forth code is very dense and my
>>Forth system might well be smaller than my C system.
>>
>>Does anyone have any experience of Forth on the Z80 who could comment? How
>>about recommendations on a Forth runtime? I was thinking of using FigForth,
>>as being small, simple and free, but I appreciate it's probably not very
>>highly optimised.

Sorry to not correspond to the original post.
The 8080 and hence the Z80 are reasonable processors.

If you are in the mainstream, have experience with C, and want a
well documented system, there are some pretty good C-compilers
around. I have used Aztek for embedded stuff, and the code generated
was good. (There was a re-entrance bug in the library, but the source
of the library was available. But that was all.)
It comes with a three volume manual etc.

I doubt that Forth is your best choice in the circumstances.
Be careful. There are some real lousy c-compilers too.

Groetjes Albert
--
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
0
albert37 (3001)
6/18/2005 9:56:27 AM
 On 17 Jun 05 at group /comp/os/cpm in article
 <RAM@regnirps.com>  (Charlie Springer)  wrote:

>On Fri, 17 Jun 2005 14:29:02 -0700, jya@ieee.org wrote
>(in article <1119043742.932693.194080@z14g2000cwz.googlegroups.com>):

>> sizeof(Forth) = sizeof(C)/2 wouldn't surprise me. By the time all
>> the source is loaded, Forth is compiled. This isn't the place to
>> write a tutorial on Forth's "under the hood" working, but one is
>> available if you want.

>I did quite a bit of Z80 (Oh, that makes me cringe) work 1997 to 2000.
>The C from ZWorld - Dynamic C - has some funny ways, but Hello World
>compiled to less than 100 bytes with init code and the works. At the
>same time we bought MPE's target compiler for Z80 and had to abandon
>it due to trouble shooting difficulties and limitations on what we
>could run and when. I don't know what the MPE products are like today
>but it looks like there has been a lot of improvement. Anyway, if I
>had a native Z80 Forth at the time I would have built a special
>motherboard for the embedded system so that I could work interactively
>without the limitations of the metacompiler-target-debugger
>connection, provided I could compile for a ROM application. I would
>have been a lot happier, fit more code into the project, and made
>changes a lot quicker.

I'm looking forward for a project with a ZWorld Rabbit 3000 Processor  
(R3k). The R3k is an optimized and improved Z80/Z180, running with  
44MHz. That's pretty fast for my process control.

The R3k is on a small subprint (50x30mm) (RCM3600), which is a complete  
microcontroller (512k Flash, 512k RAM, tons of peripherals (6! UARTS  
(IrDA, SPI, HDLC...), 7 PIOS, PWM, QUAD-Decoder, timers... )

I'm just polishing the KLS4th (a GPL ANS Forth) on it, so I can use it  
on my project.

KLS aka Ken Staton
http://pages.sbcglobal.net/statonweb/electronics/Rabbit/Rabbit_Forth.htm

KLS4th is original written for R2000, but needed some changes to run on  
the RCM3600 module.

It's crosscompiled under Gforth, the image (in the moment) must be  
shipped to the RCM under DynC GUI. HEX loader is planed, so DynC might  
be abandoned in future.

Actually the Target runs and compiles new :-definitions... and can  
modify it's flashed image.

What I'm missing:
HEX-loader
debugging words  SEE, DEBUG ....
some utilities to find the definitions in the sources.
TAG/MAP files exists, I need an interface to a standard editor.
I would prefer a hypertext editor like I have in F-PC

Anybody interested in doing some of this stuff?

Gforth runs under Linux and I'm using it under W98SE.
It is planned, that I abandon Wintel on this project.

Bye from Germany

Wolfgang


-- 
FORTHing @ work                |      *Cheap*      ...pick any
Dipl.-Ing. Wolfgang Allinger   |    *Fast* *Good*  ... *two* of them
Germany                         ------------------------------------
## KreuzPunkt XP2 R ##         |    reply address set
0
all2001 (54)
6/18/2005 12:20:00 PM
Hello, Wolfgang!

> What I'm missing:
> HEX-loader

Well... If you re-read the message published
by someone the 12 February 2003, you will
find the source code of a 8080 and 8086
Intel Hex File Format loader...

http://groups.google.fr/group/comp.os.cpm/msg/ee76f641ca52b7c9?hl=fr

Hope this helps. (Search for "LOADH86".)

Yours Sincerely,
"French Luser"



0
Bill.Gates (574)
6/18/2005 3:46:25 PM
 On 18 Jun 05 at group /comp/lang/forth in article
 <Bill.Gates@microsoft.com>  (French Luser)  wrote:

>Hope this helps. (Search for "LOADH86".)

THX

Bye from Germany

Wolfgang
-- 
FORTHing @ work                |      *Cheap*      ...pick any
Dipl.-Ing. Wolfgang Allinger   |    *Fast* *Good*  ... *two* of them
Germany                         ------------------------------------
## KreuzPunkt XP2 R ##         |    reply address set
0
all2001 (54)
6/18/2005 9:26:00 PM
David Given wrote:
> Has anyone here had any experience of programming in Forth for
> the Z80 or 8080, whether for CP/M or otherwise? Is it a good match?

I've used both FORTH and C (and assembler). Each has its strengths and
weaknesses. *Every* programming language has strengths and weaknesses.
You didn't define your problem, so it is impossible to say which
language is a good match for you.

Assembler is good because it can produce the smallest, fastest code. It
can do *anything* the computer is physically capable of. There are some
programs that *must* be written in assembler, because a high-level
language would be too slow, takes too much memory, or couldn't access
certain hardware features.

But writing in assembler is hard work; it takes a long time to write and
debug, and support and maintenace are difficult. If you ever have to
move to a different computer, start over! Most programmers (and
managers) prefer higher level languages because you can write them
faster, and with less talented people.

FORTH strikes me as one step above assembler. It is great to quickly
throw together a program to do some specific task. Compared to
assembler, it is far faster to write and test. It can be
machine-independent, so it is easier to move to another computer. For a
"high" level language, it is surprisingly fast and memory efficient (a
novice programmer can write *smaller* programs in FORTH than he can in
assembler).

But, FORTH programs tend to be "read only" -- unless well commented,
even the author can't figure out what they do later on. FORTH enforces
almost no rules, so wild-west programming styles are possible -- and
will get you in trouble later on.

C, like most other high-level languages, separates you a long ways from
the basic CPU. It allows you to generate large powerful programs fairly
quickly. It is well suited to solving traditional data processing
problems. Since C is fashionable at the moment, maintenance is easier.
So it's a good choice for big problems, when you need to move the code
to other platforms, and want other people to be able to understand and
maintain your code.

But, being farther from the CPU's roots means there is a larger
performance penalty. Debugging can be difficult. A bad or poorly-used
compiler can produce truly horrendous code. I've found C to be awkward
for real-time control and I/O manipulation; exactly the types of
problems I tend to use micros for.

Finally, there are code libraries. Libraries give you a big head start.
Good library routines serve as examples, and can do 90% of your work for
you. Without libraries, you have to write everything on your own, and
even the best language is crippled and time-consuming. A great language
with terrible libraries is worse than a terrible language with great
libraries!
--
*BE* the change that you wish to see in the world.
	-- Mahatma Gandhi
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net

0
leeahart (232)
6/20/2005 10:17:13 PM
William Meyer wrote:

(snip)

> The Z80 was designed at a time when the conventional wisdom held 
> (without any justification, btw) that an 8-bit architecture was unsuited 
> to compiled code, and even if such a (cross-)compiler could be produced, 
> the 8-bit machines most certainly could not host a competent compiler.

> So much for "wisdom". I presume that those pundits never read David 
> Gries, nor seriously studied even the state as it was then of compiler 
> design. Gries describes one compiler (which ran on 4K-words of storage, 
> IIRC) that ran 63 passes. It's not the compiler that fails, but the wit 
> of its designer.


It seems that writing compilers to run in small memory is becoming
a lost art.  There are people trying to run gcc on an IBM S/370,
with a 16M address space and about 12M available to the compiler.
It seems that is barely enough.

The IBM PL/I (F) compiler was designed to run in 44K.  (On a 64K
machine with 20K for the OS.)  It has a dynamic overlay structure
so it isn't easy to count the number of passes.  If necessary the
symbol table is stored on disk.

-- glen

0
gah (12851)
6/20/2005 10:18:38 PM
"Lee Hart" <leeahart@earthlink.net> wrote in message
news:42B75B16.5A7D@earthlink.net...
> But, FORTH programs tend to be "read only"

I've usually seen the term "write only" in this context.  Typo?  Of do you mean
something else, perhaps as in "can't be modified" ?

    - Bill


0
Bill_Leary (360)
6/20/2005 11:20:07 PM
glen herrmannsfeldt wrote:
> William Meyer wrote:
> 
> (snip)
> 
>> The Z80 was designed at a time when the conventional wisdom held 
>> (without any justification, btw) that an 8-bit architecture was 
>> unsuited to compiled code, and even if such a (cross-)compiler could 
>> be produced, the 8-bit machines most certainly could not host a 
>> competent compiler.
> 
> 
>> So much for "wisdom". I presume that those pundits never read David 
>> Gries, nor seriously studied even the state as it was then of compiler 
>> design. Gries describes one compiler (which ran on 4K-words of 
>> storage, IIRC) that ran 63 passes. It's not the compiler that fails, 
>> but the wit of its designer.
> 
> 
> 
> It seems that writing compilers to run in small memory is becoming
> a lost art.  There are people trying to run gcc on an IBM S/370,
> with a 16M address space and about 12M available to the compiler.
> It seems that is barely enough.

That's because when we had only 64K in which to play, people had to be 
clever. Now, no few try very hard to be clever, simply using host RAM to 
do qwhat they need. Were they writing for a multi-user system, such 
designs would be rude, at best. As it is, they're still not actually 
very efficient, because the authors aren't giving efficiency any attention.

> The IBM PL/I (F) compiler was designed to run in 44K.  (On a 64K
> machine with 20K for the OS.)  It has a dynamic overlay structure
> so it isn't easy to count the number of passes.  If necessary the
> symbol table is stored on disk.

David Gries, in his volume on compiler design (1971) describes a 
compiler (FORTRAN, if memory serves) that was designed to run in 63 
passes on a machine with only 4KWords of memory. Now that's clever.

Bill
0
wmeyer (59)
6/21/2005 12:24:26 AM
>> But, FORTH programs tend to be "read only"

Bill Leary wrote:
> I've usually seen the term "write only" in this context. Typo?

Yes, I'm sorry; that was a typo. I meant to say "FORTH programs tend to
be WRITE-only", i.e. you can write and use them, but the source is not
likely to make much sense to anyone else (even the author) unless it is
heavily and carefully commented.
-- 
If you would not be forgotten
When your body's dead and rotten
Then write of great deeds worth the reading
Or do the great deeds worth repeating
	-- Ben Franklin, Poor Richard's Almanac
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net

0
leeahart (232)
6/21/2005 5:28:27 AM
Lee Hart wrote:

> problems. Since C is fashionable at the moment, maintenance is easier.
> So it's a good choice for big problems, when you need to move the code

Sure, I know that being in fashion sure helps maintenence around here.
We require all our janitors to wear the latest fashions so that work
is done better.

0
6/21/2005 6:46:16 PM
glen herrmannsfeldt wrote:

> It seems that writing compilers to run in small memory is becoming
> a lost art.  There are people trying to run gcc on an IBM S/370,
> with a 16M address space and about 12M available to the compiler.
> It seems that is barely enough.
> 

Yep, writing compilers that syncronize with magnetic drum memory is
a lost art too[*]. Any takers ?

* - No, I am not kidding. In the old days the passes and the data
areas in a compiler were synced to the revolution of the drum.

0
6/21/2005 6:49:21 PM
William Meyer wrote:

> David Gries, in his volume on compiler design (1971) describes a 
> compiler (FORTRAN, if memory serves) that was designed to run in 63 
> passes on a machine with only 4KWords of memory. Now that's clever.
> 
> Bill

True, but not an 8 bit machine, more like about 40 bits or so. Ie, more
like 20k in byte terms.

0
6/21/2005 6:51:48 PM
>> It seems that writing compilers to run in small memory is becoming
>> a lost art.  There are people trying to run gcc on an IBM S/370,
>> with a 16M address space and about 12M available to the compiler.
>> It seems that is barely enough.
>>
>
> Yep, writing compilers that syncronize with magnetic drum memory is
> a lost art too[*]. Any takers ?
>
> * - No, I am not kidding. In the old days the passes and the data
> areas in a compiler were synced to the revolution of the drum.

I used one of those but there was no compiler when I started working.  We 
had to use machine language and put each byte of code on the drum ourselves 
to account for the drum's rotation in relation to the time to execute a 
given instruction.  When the first compiler came out that did this 
automatically, we were in Heaven!  I didn't think computers could get any 
better than that.

Tom L 


0
tlake (477)
6/21/2005 8:45:25 PM
Hi
 I find that the "write only" tends to be for beginners
both in writing and in reading. Since I've been using
a streamy source input type Forth, ( typical of most modern
Forth's ) I tend to use white space more effectively.
I tend to put just one thought, that might be composed
of several words, on each line. I indent for flow control
structures as well. Good choice of names for the application
words make it almost like reading sentences.
 Not only do I find that I can pull out older code and read it
but I also often cut and paste pieces to reuse.
 I'll admitt that it takes a little longer to get to this
point of understanding when programming in Forth as compared
to languages like C. The difficulty I have with langauges
like C is that no matter how high a level of abstraction one
gets to, the language is still dominant over the application.
In well written Forth the application becomes the dominant
part on the page. As a comparison, a language like BASIC is
almost always readible but lacks the application context.
I see languages like C as a halfway step.
 Back to my original point. When I was using block source
code, I didn't use white space as effectively and tended to
write "write only" code.
Dwight


Lee Hart wrote:
> >> But, FORTH programs tend to be "read only"
>
> Bill Leary wrote:
> > I've usually seen the term "write only" in this context. Typo?
>
> Yes, I'm sorry; that was a typo. I meant to say "FORTH programs tend to
> be WRITE-only", i.e. you can write and use them, but the source is not
> likely to make much sense to anyone else (even the author) unless it is
> heavily and carefully commented.
> --
> If you would not be forgotten
> When your body's dead and rotten
> Then write of great deeds worth the reading
> Or do the great deeds worth repeating
> 	-- Ben Franklin, Poor Richard's Almanac
> --
> Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net

0
dkelvey (274)
6/21/2005 10:18:07 PM
Scott Moore wrote:
> Yep, writing compilers that syncronize with magnetic drum memory is
> a lost art too[*]. Any takers ?
> 
> * - No, I am not kidding. In the old days the passes and the data
> areas in a compiler were synced to the revolution of the drum.

THe difference is that we no longer need to sync with rotating memory, 
but there are many things we do need to work on that are too large to 
simply cram into RAM because we're too lazy to do something more 
intelligent.

Bill

0
wmeyer (59)
6/21/2005 11:06:41 PM
Scott Moore wrote:
> glen herrmannsfeldt wrote:
> 
> 
>>It seems that writing compilers to run in small memory is becoming
>>a lost art.  There are people trying to run gcc on an IBM S/370,
>>with a 16M address space and about 12M available to the compiler.
>>It seems that is barely enough.

> Yep, writing compilers that syncronize with magnetic drum memory is
> a lost art too[*]. Any takers ?

If you can find a 2301 I will try to write a compiler using it.
I don't think there are many around anymore, though.

> * - No, I am not kidding. In the old days the passes and the data
> areas in a compiler were synced to the revolution of the drum.

-- glen

0
gah (12851)
6/21/2005 11:26:58 PM
William Meyer wrote:
> Scott Moore wrote:
> 
>>Yep, writing compilers that syncronize with magnetic drum memory is
>>a lost art too[*]. Any takers ?
>>
>>* - No, I am not kidding. In the old days the passes and the data
>>areas in a compiler were synced to the revolution of the drum.
> 
> 
> THe difference is that we no longer need to sync with rotating memory, 
> but there are many things we do need to work on that are too large to 
> simply cram into RAM because we're too lazy to do something more 
> intelligent.
> 
> Bill
> 

The present reality is simply that you have to develop on a host machine
that is not your 64kb constricted Z80/8080/8 bit whatever. It was this way
when microprocessors started, Intel and others assumed that micros couldn't
support an operating system and tools. Then kindall showed that they could,
abet a minimal system. Was that amazing ? Sure. However, the reason for
wanting to develop on a micro was that the typical PDP-11 used for development
was very expensive. Now with PCs, it makes no sense to develop on the target
micro, which is typically used for embedded purposes now.

Can you still develop on a micro ? Sure. But to have high powered optimization,
you are going to need a fairly large and complex compiler to target that
micro.

There is a loop function here. In order to fit the compiler on the micro,
you are going to have to reduce its complexity, which means not doing a good
job of optimization, which means that the size of the compiler grows, which
means that you have to reduce its complexity, etc, etc.

I have been in this loop. Our compiler came from the Z80 at about 48kb, and
now is a 1mb monster. If/when I add back Z80 support, it will never fit
back into a Z80 ever again, those days are gone. Even back in the Z80
days, I was continually running up against the memory limits on the machine,
it was not fun.

Its just a basic tauntolgy: Processors like the Z80 have small memory space
and low instruction count (like lack of multiply, etc), and are non-orthogonal,
so actually need MORE work to optimize for than, say, a RISC processor. So
they are going to be in need of a larger compiler than most.

0
6/21/2005 11:40:23 PM

Scott Moore wrote:
> William Meyer wrote:
> > Scott Moore wrote:
> >
> >>Yep, writing compilers that syncronize with magnetic drum memory is
> >>a lost art too[*]. Any takers ?
> >>
> >>* - No, I am not kidding. In the old days the passes and the data
> >>areas in a compiler were synced to the revolution of the drum.
> >
> >
> > THe difference is that we no longer need to sync with rotating memory,
> > but there are many things we do need to work on that are too large to
> > simply cram into RAM because we're too lazy to do something more
> > intelligent.
> >
> > Bill
> >
>
> The present reality is simply that you have to develop on a host machine
> that is not your 64kb constricted Z80/8080/8 bit whatever. It was this way
> when microprocessors started, Intel and others assumed that micros couldn't
> support an operating system and tools. Then kindall showed that they could,
> abet a minimal system. Was that amazing ? Sure. However, the reason for
> wanting to develop on a micro was that the typical PDP-11 used for development
> was very expensive. Now with PCs, it makes no sense to develop on the target
> micro, which is typically used for embedded purposes now.
>
> Can you still develop on a micro ? Sure. But to have high powered optimization,
> you are going to need a fairly large and complex compiler to target that
> micro.
>
> There is a loop function here. In order to fit the compiler on the micro,
> you are going to have to reduce its complexity, which means not doing a good
> job of optimization, which means that the size of the compiler grows, which
> means that you have to reduce its complexity, etc, etc.
>
> I have been in this loop. Our compiler came from the Z80 at about 48kb, and
> now is a 1mb monster. If/when I add back Z80 support, it will never fit
> back into a Z80 ever again, those days are gone. Even back in the Z80
> days, I was continually running up against the memory limits on the machine,
> it was not fun.
>
> Its just a basic tauntolgy: Processors like the Z80 have small memory space
> and low instruction count (like lack of multiply, etc), and are non-orthogonal,
> so actually need MORE work to optimize for than, say, a RISC processor. So
> they are going to be in need of a larger compiler than most.

Not a concern on the tms9900 - since noone will ever support it! No
cross-compilers, only cross-assemblers!

But who cares anyway? TI users only seem interested in hardware these
days, even if they can't do anything with it except play their 20 year
old games...

But I digress and am off topic... excuse me.

0
anoneds (102)
6/22/2005 1:23:42 AM
"Tom Lake" <tlake@twcny.rr.com> wrote in message
news:F%_te.31377$fp6.18602@twister.nyroc.rr.com...
> >> It seems that writing compilers to run in small memory is becoming
> >> a lost art.  There are people trying to run gcc on an IBM S/370,
> >> with a 16M address space and about 12M available to the compiler.
> >> It seems that is barely enough.
> >>
> >
> > Yep, writing compilers that syncronize with magnetic drum memory is
> > a lost art too[*]. Any takers ?
> >
> > * - No, I am not kidding. In the old days the passes and the data
> > areas in a compiler were synced to the revolution of the drum.
>
> I used one of those but there was no compiler when I started working.  We
> had to use machine language and put each byte of code on the drum ourselves
> to account for the drum's rotation in relation to the time to execute a
> given instruction.  When the first compiler came out that did this
> automatically, we were in Heaven!  I didn't think computers could get any
> better than that.

The classic "Story of Mel" uses one of these types of machines.

http://www.wizzy.com/andyr/Mel.html

    - Bill


0
Bill_Leary (360)
6/22/2005 3:29:36 AM
dkelvey@hotmail.com wrote:
>  I find that the "write only" tends to be for beginners
> both in writing and in reading. Since I've been using a
> streamy source input type Forth, ( typical of most modern
> Forth's ) I tend to use white space more effectively.
> I tend to put just one thought, that might be composed
> of several words, on each line. I indent for flow control
> structures as well. Good choice of names for the application
> words make it almost like reading sentences...

> The difficulty I have with langauges like C is that no matter
> how high a level of abstraction one gets to, the language is
> still dominant over the application. In well written Forth the
> application becomes the dominant part on the page. As a comparison,
> a language like BASIC is almost always readable but lacks the
> application context.

Great comments, Dwight. I agree.

Forth has minimal enforcement of rules and standards; thus novice
programmers can go "wild" and do all sorts of things that seem like a
good idea at the time, but that they will regret later. More experienced
programmers apply their own rules and standards even when the language
itself does not require them.

Also, Forth lends itself to a wider range of applications because you
modify it to suit the problem at hand. In effect, you are writing a
language specifically suited to solving the problem. This is good for
many reasons, but puts the onus on the programmer to *document* his new
language!
-- 
Humanity is acquiring all the right technology for all the wrong
reasons.
	-- R. Buckminster Fuller
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net

0
leeahart (232)
6/22/2005 5:00:50 PM
Wow what a great thread on the Z80 produced from an uncomplicated =
question

I just got back from holiday and found it waiting - it could be =
published as a book.
Although I cannot add any more I would like to thank everyone who has =
contributed.
- and what a great CPU,


"David Given" <dg@cowlark.com> wrote in message =
news:CiEre.23591$iy2.7519@newsfe1-gui.ntli.net...
> I'm posting this here because I suspect that this is one of the few
> newsgroups where people might actually know the answer...
>=20

0
noSpam6691 (11)
6/23/2005 9:54:37 AM
Z80 wrote:
[...]
> Wow what a great thread on the Z80 produced from an uncomplicated question

Yes, I'd just like to say thanks for a whole load of extremely interesting
and informative pointers, which I have been largely remiss in replying to
(due to a sudden and unforseen deluge of C++ coding and plaster --- don't
ask).

I'm going to give the Forth interpreter a try, and see how it goes. Apart
from anything else, I'm a extreme Forth novice and the discipline necessary
in writing a useful program in such an unfamiliar language will be a useful
exercise.

I'll report back if it works...

-- 
+- David Given --McQ-+ "There is no expedient to which a man will not
|  dg@cowlark.com    | resort to avoid the real labour of thinking." ---
| (dg@tao-group.com) | Thomas Edison
+- www.cowlark.com --+ 

0
dg (326)
6/23/2005 3:48:11 PM
David Given wrote:
> I'm going to give the Forth interpreter a try, and see how it goes.
> Apart from anything else, I'm a extreme Forth novice and the
> discipline necessary in writing a useful program in such an
> unfamiliar language will be a useful exercise.

Get the book "Starting Forth" by Leo Brodie. It's the best beginner's
guide I know of.
-- 
Ring the bells that you can ring
Forget your perfect offering
There is a crack in everything
That's how the light gets in
	-- Leonard Cohen, from "Anthem"
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net

0
leeahart (232)
6/25/2005 7:21:27 PM
Lee Hart wrote:
> David Given wrote:
> 
>>I'm going to give the Forth interpreter a try, and see how it goes.
>>Apart from anything else, I'm a extreme Forth novice and the
>>discipline necessary in writing a useful program in such an
>>unfamiliar language will be a useful exercise.
> 
> 
> Get the book "Starting Forth" by Leo Brodie. It's the best beginner's
> guide I know of.
On line at
http://www.amresearch.com/starting_forth/
Might want to check out
http://home.earthlink.net/~lbrodie/
also.  Leo Brodie's home page with links to a PDF of the 2004 edition 
for download and to Amazon for purchase.
0
bobwyates (14)
6/25/2005 10:12:19 PM
On Sat, 25 Jun 2005 22:12:19 GMT, Bob Yates <bobwyates@earthlink.net> wrote:
>Lee Hart wrote:
>> David Given wrote:
>> 
>>>I'm going to give the Forth interpreter a try, and see how it goes.
>>>Apart from anything else, I'm a extreme Forth novice and the
>>>discipline necessary in writing a useful program in such an
>>>unfamiliar language will be a useful exercise.
>> 
>> 
>> Get the book "Starting Forth" by Leo Brodie. It's the best beginner's
>> guide I know of.
>On line at
>http://www.amresearch.com/starting_forth/
>Might want to check out
>http://home.earthlink.net/~lbrodie/
>also.  Leo Brodie's home page with links to a PDF of the 2004 edition 
>for download and to Amazon for purchase.

See also http://thinking-forth.sourceforge.net
For another of Brodies escellent books...
-- 
Cheers,
Stan Barr     stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!
0
stanb45 (75)
6/26/2005 7:41:18 AM
Stan Barr wrote:
[...]
> See also http://thinking-forth.sourceforge.net
> For another of Brodies escellent books...

Thanks --- it's very interesting reading (and I should check out any local
POD shops so I can get a hard copy).

-- 
+- David Given --McQ-+ (base 10) = (base pi)
|  dg@cowlark.com    | 1 = 1; 2 = 2; 3 = 3
| (dg@tao-group.com) | 3.1415926... = 10.0
+- www.cowlark.com --+ 4 = 12.201220211...

0
dg (326)
6/27/2005 12:12:56 PM
David Given wrote:

> anoneds@netscape.net wrote:
> [...]
> 
>>Results were (for fib(20)):
>>
>>3.5 seconds - c99, small C compiler
>>9   seconds - TI Forth
>>17  seconds - Wycove Forth
> 
> 
> That's fascinating; c99 and TI Forth are *well* within the same order of
> magnitude. TI Forth is a FigForth derivative, isn't it? Do you have a link?
> I'd like to have a look at the documentation --- I don't know anything
> about the 9900.
> 
Forget Forth; forget Small C and Tiny C.  Get BDS C, which is no 
available in the public domain.

BDS C is very, very fast, in both compiling and run time.

Jack
0
jcrens (282)
7/8/2005 2:21:38 PM

David Given wrote:
> I'm posting this here because I suspect that this is one of the few
> newsgroups where people might actually know the answer...
>
> I want to write a program for a Z80 platform. (Potentially running CP/M,
> although that's not terribly relevant.) It needs to be efficient and small.
>
> I do *not* want to write this in Z80 assembly; I hate the stuff. So, I need
> another language. Normally I'd write this sort of thing in C, except that C
> compilers for the Z80 produce lousy code, in part due to the Z80's design.
>
> Would I be better off writing in Forth instead?
>
> Forth will generate threaded code that will need to be interpreted, which
> produces an immediate performance hit. *However*, given that Forth
> interpreters are damned fast, and that the C code we're comparing it with
> is very bad, I think there's a reasonable chance that they'll be within the
> same order of magnitude at least. Plus, Forth code is very dense and my
> Forth system might well be smaller than my C system.
>
> Does anyone have any experience of Forth on the Z80 who could comment? How
> about recommendations on a Forth runtime? I was thinking of using FigForth,
> as being small, simple and free, but I appreciate it's probably not very
> highly optimised.
>
> --
> +- David Given --McQ-+
> |  dg@cowlark.com    | C:\DOS, C:\DOS\RUN, RUN\DOS\RUN
> | (dg@tao-group.com) |
> +- www.cowlark.com --+

This topic draw my attention because I remembered finding something
about forth on one of my disks, however, I have no idea what's the
perpose of forth. I have something called F83, but what can it do?? It
seems to me like forth is not really a programming language but more
like an alternative system running inside another system (like CP/M).
And also, I see things like "creates a file with 37 screens". What is
all that about?

Michel
http://cpm.sytes.net

0
michel510 (33)
7/9/2005 4:38:05 AM
On 8 Jul 2005 21:38:05 -0700, michel <michel@xiac.com> wrote:
>
>This topic draw my attention because I remembered finding something
>about forth on one of my disks, however, I have no idea what's the
>perpose of forth. I have something called F83, but what can it do?? It
>seems to me like forth is not really a programming language but more
>like an alternative system running inside another system (like CP/M).
>And also, I see things like "creates a file with 37 screens". What is
>all that about?

Forth can, and does, do anything.  F83 is an early (1983 Standard) Forth,
but quite capable of real work.  I used to use it a lot on TRS-80, MSDOS
and CP/M.  Forth can run stand-alone or under another operating system,
but mostly the latter these days, except for embedded applications.
Screens are a method used by early Forths for storing source code etc.
as 1K blocks of data that are automatically paged in and out of buffers 
as required.

See: http://forth.sourceforge.net/website/forthlinks/ for some links.

-- 
Cheers,
Stan Barr     stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!
0
stanb45 (75)
7/9/2005 11:14:54 AM
On 8 Jul 2005 21:38:05 -0700, "michel" <michel@xiac.com> wrote:

>This topic draw my attention because I remembered finding something
>about forth on one of my disks, however, I have no idea what's the
>perpose of forth. 

Seems to me I used to get a lot of Forth stuff on the hard drives
and floppies coming out of the Kitt Peak stuff; it would simply
be mixed in with the surplus, then sold at University of Arizona
monthly auctions.

Might tend to confirm an earlier opinion that appeared maybe
a couple months ago, that Forth was used to control telescopes?

Don't know for sure what's still in my 'pile' but maybe I'll
have something interesting. Maybe.

Bill

0
Bill3039 (326)
7/16/2005 3:54:00 AM
"wild bill" <bill@sunsouthwest.com> wrote in message
news:tkd5d1hcodu2ual92t7ggcq6i160loht9h@4ax.com...
> Seems to me I used to get a lot of Forth stuff on the hard drives
> and floppies coming out of the Kitt Peak stuff; it would simply
> be mixed in with the surplus, then sold at University of Arizona
> monthly auctions.
>
> Might tend to confirm an earlier opinion that appeared maybe
> a couple months ago, that Forth was used to control telescopes?

Forth started out in the '60's, but yes (more or less).

From the Forth Inc. web site:  "Moore developed the first complete, stand-alone
implementation of Forth in 1971 for the 11-meter radio telescope operated by the
National Radio Astronomy Observatory (NRAO) at Kitt Peak, Arizona."

See : http://www.forth.com/resources/evolution/evolve_2.html#2.1

The quote above is from the first paragraph in section 2.1 reached from the
above URL.

    - Bill


0
Bill_Leary (360)
7/16/2005 11:56:26 AM

Bill Leary wrote:
> "wild bill" <bill@sunsouthwest.com> wrote in message
> news:tkd5d1hcodu2ual92t7ggcq6i160loht9h@4ax.com...
> > Seems to me I used to get a lot of Forth stuff on the hard drives
> > and floppies coming out of the Kitt Peak stuff; it would simply
> > be mixed in with the surplus, then sold at University of Arizona
> > monthly auctions.
> >
> > Might tend to confirm an earlier opinion that appeared maybe
> > a couple months ago, that Forth was used to control telescopes?
>
> Forth started out in the '60's, but yes (more or less).
>
> From the Forth Inc. web site:  "Moore developed the first complete, stand-alone
> implementation of Forth in 1971 for the 11-meter radio telescope operated by the
> National Radio Astronomy Observatory (NRAO) at Kitt Peak, Arizona."
>
> See : http://www.forth.com/resources/evolution/evolve_2.html#2.1
>
> The quote above is from the first paragraph in section 2.1 reached from the
> above URL.
>
>     - Bill

Hi Bill
 Forth was used at Kitt Peak quite a bit. They even publish
a manual for it. The main reason for using it there was that
it allowed a simple multi-tasker that could have many users
on smaller systems. Chuck Moore says the first code that had
the feel of Forth was done at a carpet company. By the time
it was used at Kitt Peak, it was a complete language.
 It would be interesting to see what some of the code was
that they used.
Dwight

0
dkelvey (274)
7/21/2005 4:39:17 PM
<dkelvey@hotmail.com> wrote in message
news:1121963957.231594.4460@z14g2000cwz.googlegroups.com...
> Bill Leary wrote:
> > Forth started out in the '60's, but yes (more or less).
> >
> > From the Forth Inc. web site:  "Moore developed the first complete,
stand-alone
> > implementation of Forth in 1971 for the 11-meter radio telescope operated by
the
> > National Radio Astronomy Observatory (NRAO) at Kitt Peak, Arizona."
> >
> > See : http://www.forth.com/resources/evolution/evolve_2.html#2.1
> >
> > The quote above is from the first paragraph in section 2.1 reached from the
> > above URL.
>
>  Forth was used at Kitt Peak quite a bit. They even publish
> a manual for it. The main reason for using it there was that
> it allowed a simple multi-tasker that could have many users
> on smaller systems. Chuck Moore says the first code that had
> the feel of Forth was done at a carpet company. By the time
> it was used at Kitt Peak, it was a complete language.
>  It would be interesting to see what some of the code was
> that they used.

Yes, I'm aware of the background.  My intention was to respond to the point
about Kitt Peak in the message I replied to.  The article I referenced goes into
much of what you've said as well, thought I don't think it explicitly mentioned
a carpet company.  Interesting bit of information there.  Thanks.

As much as I love the concepts behind forth, I've never really been able to
program in it very well.  Something about how it uses the stacks gives me
trouble that I've never been able to root out and get past.  I'd have thought
that programming so much assembler would help, but (at least in my case) it
doesn't.

    - Bill


0
Bill_Leary (360)
7/21/2005 10:49:16 PM
Reply:

Similar Artilces:

Re: C vs Forth on the Z80 (or 8080)
> Message-ID: <E1DiYu2-0003op-KP@stasis.kostecke.net> David Given <dg@cowlark.com> wrote: > Kelly Hall wrote: > > In other words, I'm happy to write small, easy programs in assembly on a > > Z80. For anything substantial, I'd just as soon use C or something else > > I'm used to orthogonal ISAs like ARM or MCore. The Z80 is so unorthogonal it > makes me faintly nauseous. Which means that writing anything more than tiny The Z80's wonderfully orthogonal, almost as ortogonal at the pdp11 and ARM: 01<dst><src> is always LD ...

Re: C vs Forth on the Z80 (or 8080) #2
> Message-ID: <E1DjGS2-0001vy-8e@stasis.kostecke.net> nospam@nouce.bellatlantic.net wrote: > On 17 Jun 05 00:15:07 GMT, jgh@arcade.demon.co.uk (Jonathan Graham > Harston) wrote: > >The Z80's wonderfully orthogonal, almost as ortogonal at the pdp11 > >and ARM: > > > >01<dst><src> is always LD dst,src, even 'silly' ops like LD A,A > >10<ula><src> is always <ula operation> A,src > >00<dst>110 is always LD <dst>,n > >11<ula>110 is always <ula operation> A,n > >...

Forth and AI (Was Re: C vs Forth, was Howerd's ANN : Forth Versus C
Jeff, I would be interested in hearing your experiences using Forth with AI. Steve Graham === Bill Spight <Xbspight@pacbell.net> wrote in message news:<4095C3EA.1549F111@pacbell.net>... >>> > Symbolic Computations on a Personal Computer, -- S. N. Baranoff >>> > >>> > List Processing and Object-Oriented Programming Using Forth, -- >>> > Dennis L Feucht >> It might be interesting to hear from Messers Baranoff and Feucht bout >> the difficulties and trade-offs of using Forth for symbolic >> computati...

Matlab vs C++ vs C#
Which of these should a person interested in financial modeling learn? "BB" <bb.donotmail@nomail.invalid> wrote in message news:ef1020b.-1@webx.raydaftYaTP... > Which of these should a person interested in financial modeling > learn? > If these are your only options, I would pick Matlab myself. You do much more with Matlab in much less time. Also debugging in Matlab is easy. Matlab also has a financial toolbox http://www.mathworks.com/access/helpdesk/help/toolbox/finance/finance.shtml Nasser Nasser Abbasi wrote: > > "BB" <bb.donotmai...

C vs. C++ vs. Java
Hi! I'dont have any experiences in programming... what language should I start learning???? C? C++ or Java`? greetz Start with C go on to C++ and then on to JAVA. And you will C what how that helps. priyasmita_guha@yahoo.co.in wrote: > Start with C go on to C++ and then on to JAVA. > And you will C what how that helps. The OP's question is not topical to this group. It would be better answered in comp.programming among others. Please try to redirect off topic questions rather than answering them here. hi there! i think u sho0uld start wid C language and LET US C is an x...

C vs Forth vs whatever Executables for Hello World
In a recent thread in comp.arch.embedded entitled "Where does C++ fit in?" some people were comparing executables for C and C++ for Hello World examples. Now I know a .COM file in DOS can do it in <30 bytes. But I was supprised to see the size of the executables generated by C and C++ (presumably for a Linux system (and in a thread about where C++ fits into embedded system use). Those numbers ranged from about 2700 to 388,000 ( -static) after the application of -strip. With -static and before -strip the size was a whopping 1.7M. Now I know that TCOM when targeting for DOS prod...

*tuple vs tuple example print os.path.join(os.path.dirname(os.tmpnam()),*("a","b","c"))
I have been trying to find documentation on the behavior Can anyone tell me why the first example works and the second doesn't and where I can read about it in the language reference? Steve print os.path.join(os.path.dirname(os.tmpnam()),*("a","b","c")) #works OUTPUT:/var/tmp/a/b/c and print os.path.join(os.path.dirname(os.tmpnam()),("a","b","c")) # doesn't OUTPUT:Traceback (most recent call last): File "<stdin>", line 1, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/pyth...

Cellular automata benchmarks: Java vs C++ vs Java vs C++
I love benchmarking. Here are some very interesting results which compare different cellular automata implementations in C++ and Java, with different versions of the Java VM: Sun vs Microsoft (MS). MCell is a Windoze C++ program, MJCell is MCell ported to Java, SARCASim is a 5++ year old C++ Windoze program of mine and my Modern Cellular Automata Java applet is rather unique. Because of restrictions in the size of MJCell's universes almost all benchmarks were performed using an 800 by 600 universe. All benchmarks were performed using the Brian's Brain three state cellular a...

OS Smackdown: Linux vs OS X vs Vista vs XP
Mount your soapboxes fanboys of all denominations - It's playtime... OS Smackdown: Linux vs. Mac OS X vs. Windows Vista vs. Windows XP Since the dawn of time - or, at least, the dawn of personal computers - the holy wars over desktop operating systems have raged, with each faction proclaiming the unrivaled superiority of its chosen OS and the vile loathsomeness of all others. No matter how fierce the language or convincing the arguments, however, these battles began to seem somewhat irrelevant to regular working stiffs. While Mac OS, OS/2, Linux and many other desktop operating systems...

floating point programming: c/c++ vs matlab vs fortran vs ???
Dear all, I am helping someone code a model of an optical amplifier in C code (with the aim of verifying results published by someone else). The model seems to behave correctly for a limited range of parameters, but is quite off outside this range. This is unacceptable; AFAICT theres no algorithmic reason the model should fail, so I suspect things are going wrong in floating point land. As I've been reading up on the matter I find there is a lot that could be going wrong: floating point exceptions, rounding errors etc. The model can be run reasonably quick, so we'd happily sacrifice ...

Obj-C vs. C++ for New Mac OS X Development
I am a long time (>> 20 years) UNIX C/C++ developer. I have recently found a lot of spare time so I have spent the last two months studying Obj-C and the Apple PB/IB tools. I am very impressed by the depth of the Foundation and Application Kits that Apple provides. I have an academic license for CW that I have not kept updated, so I cn not compare CW8 or CW9 to the apple tools. I am in the process of writing several shareware programs. I have about 80% of the code written in ANSI C or C++. i am adding the GUI using PB/IB and Obj-C. I really appreciate the ease of cons...

Fortran Vs C, C++, C#
What can Fortran do that C, C++, C# can't? Along similar lines where would Fortran be a superior chice over C, C+ +, or C# Jeff RF ENGINEER55 > What can Fortran do that C, C++, C# can't? > > Along similar lines where would Fortran be a superior chice over C, C+ > +, or C# None that I know of. Here is a dated (1992) paper comparing F77, F90, C and C++ for engineering pgrograms: http://www.leshatton.org/Documents/JSX_0192.pdf Me, myself and I, we all prefer C++. I like strong typing and mandatory function prototypes. I also like function overloa...

Android vs Qt vs C/C++
Hi All, I am a mobile application developer and this is the first time i have entered into developing an embedded application from scratch. I know that the title is a bit misleading and there will be rebuts in the grounds that Android is an OS and Qt is a framework and C/C++ is a language. Let me explain my requirement. I need to develop an embedded device which will be installed in a vehicle and it will periodically send telemetrics data to the cloud server using GSM modem. The telemetrics will include 1. GPS position data 2. Accelerometer readings 3. Image/Video data 4. It needs to li...

OS Smackdown: Linux vs. Mac OS X vs. Vista vs. XP
OS Smackdown: Linux vs. Mac OS X vs. Vista vs. XP Michael DeAgonia, Preston Gralla, David Ramel and James Turner, Computerworld http://www.pcworld.com/businesscenter/article/147262/os_smackdown_linux_vs_mac_os_x_vs_vista_vs_xp.html In comp.os.linux.advocacy, Ablang <ron916@gmail.com> wrote on Fri, 20 Jun 2008 19:48:30 -0700 (PDT) <1fc9ff8c-d6e9-486b-956b-a34f943d8699@m3g2000hsc.googlegroups.com>: > OS Smackdown: Linux vs. Mac OS X vs. Vista vs. XP > > Michael DeAgonia, Preston Gralla, David Ramel and James Turner, > Computerworld > > http://www.pcworld.com/bu...

INSPECT: OS/VS vs. IBM Enterprise COBOL for z/OS and OS/390 3.2.0
All righty... as mentioned the other day I coded: 01 CHAR-1 PIC X. 01 CHAR-80 PIC X(80). .... PROCEDURE DIVISION. PERFORM INSPECT-1. PERFORM INSPECT-80. GOBACK. INSPECT-1. INSPECT CHAR-1 REPLACING ALL 'a' BY 'A'. INSPECT-80. INSPECT CHAR-80 REPLACING ALL 'a' BY 'A' ALL 'b' B...

C vs. C++
What is the main difference between C and C++. If I were to choose one to study so as to learn about game development which should I choose and why? Thx, R.Spinks R.Spinks wrote: > What is the main difference between C and C++. If I were to choose one to > study so as to learn about game development which should I choose and why? > > Thx, > > R.Spinks > > C++ is a superset of C, adding Object Oriented programming and Generics via templates. C++ is the main programming language of game developers, so it is very relevant to the industry. ...

C++ vs. C#
Very recently, I started a thread enquiring about the C++ object model. All that remains in my mind about that thread is: "why would you want to do that?", and "it's not portable" and probably other irrelevancy (read, no real answers). I spoke of "Lightweight" vs. "Heavyweight" objects. And of "representation in memory of an object" as important. Well guess what? I stumbled upon some C# description pages of structs, classes and the like. Guess what? What seems to be in this NG as "don't do that" and "non-portable", ...

C++ vs C
Hello, I'm writing an embedded application and I'm trying to decide whether to do it in C or C++. Does anyone know where I can find some statistic data comparing the two languages (size and performance)? Thanks, Nataly natush wrote: > Hello, > I'm writing an embedded application and I'm trying to decide whether to > do it in C or C++. Does anyone know where I can find some statistic > data comparing the two languages (size and performance)? > > Thanks, > Nataly Hi Nataly, I don't think that you can make a comparison between the two languages (in ...

C vs. C++
Hi everybody No trolling here, but I just thought C++ was just object oriented C but I was recently surprised to learn that C was much more used in numerical, computational physics. So here's my question : why would C be better for this kind of programming. beggars.banquet@gmail.com wrote: > Hi everybody > No trolling here, but I just thought C++ was just object oriented C > but I was recently surprised to learn that C was much more used in > numerical, computational physics. So here's my question : why would C > be better for this kind of programming. Physicists tend ...

C++ vs C
I've just been working with a bit of C++ code for the first time (with a view to spending a couple of hours converting it to C. Or to *any* language that mere humans could understand, for that matter). But after that experience I don't think I'll ever complain about anything in C again! The thing was bristling with templates, specialisation templates, classes, namespaces, operators, friends, the full works, used, as far as I could see, just for the sake of it. (I managed to get rid of the templates, and it still worked..) This was a jpeg encoder/decoder, a comp...

obj-c vs c++ vc c
what are the differences between obj-c and c++? obj-c and c? i'm learning c at the moment, and i when i'm ready i want to take the "next step" to either c++ or obj-c, but i'm not sure which. jesse jesse wrote: > > i'm learning c at the moment, and i when i'm ready i want to take the "next > step" to either c++ or obj-c, but i'm not sure which. C++ is a lot more popular and so is more useful in the "real world". Objective-C is a very nice language but is poorly adopted. On the other hand, if you are working ...

C vs. C++ and gcc/g++ vs. cc/CC
Having written a simple test application (which does the same in C and C++) I got the following results: with C++ the app compiled with g++ is about 20% faster than with the MIPSPro CC. with C the app compiled with MIPSPro cc is 3-4 times faster than compiled with gcc. The gcc/c app is 30-40% faster than the same g++/c++ app. The MIPS/c app is several times faster than the MIPS/c++ app. I always compiled with "-O3". For the C++ app I used valarrays, for the C app float[]. Is this the general performance line or is it only for my special test application? F...

Calling C/C++ for Z/OS from Rexx for Z/OS
Hello, i have the following question: does anybody have experience or knowledge how to call a c/c++ programm on z/os from a rexx, which runs under z/os and tso - and for sure retrieve more than a simple go/nogo from the c programm by the calling rexx? I'm absolutly uncertain i that works at all under z/os. regards Fritz In <1176720931.867910.113190@y80g2000hsf.googlegroups.com>, on 04/16/2007 at 03:55 AM, "fritz" <fritzrapp@t-online.de> said: >does anybody have experience or knowledge how to call a c/c++ >programm on z/os from a rexx, which runs under z/os...

C vs. C++ and C compiler optimization question
/* Consider the following C snippet: */ Foo *pFoo = NULL; void FooLength(Foo *pFoo); void FooHello(Foo **ppFoo); void FooWorld(Foo **ppFoo); void FooLength(Foo *pFoo) { int count = 0; for (Foo *p = pFoo; *p; p++) ++count; return count; } void FooHello(Foo **ppFoo) { int count = FooLength(*ppFoo); // ... } void FooWorld(Foo **ppFoo) { int count = FooLength(*ppFoo); // ... } // Consider the following C++ snippet: class FooHelloWorld { public: void FooHello(Foo **ppFoo) { iCount = FooLength(*ppFoo); // ... } void FooWorld(Foo *...