Please see embedded remarks below.
Dick
----- Original Message -----
From: ajp166 <ajp166_at_bellatlantic.net>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, October 29, 2000 11:54 AM
Subject: Re: Monitor for iSBC 8024
> From: Richard Erlacher <richard_at_idcomm.com>
> >> From: Richard Erlacher <richard_at_idcomm.com>
> >>
> >>
> >> Use the editor that comes with the mailer, please.
> >>
> >
> >What???
>
It's the term "mailer" that confused me.
>
> Unless your system is severely crippled your Email has an
> editor that will allow your to strip the excess non relevent text.
> Try it, make it easier to read on the other end.
>
> >> I havent a clue why you said that at all since the origin of the
> smallc-c
> >> compiler is 8080? I still have the original DDJ articles with
> sources.
> >>
> >What I said (I thought) was that I don't want to fiddle with small-C to
> the
> >extent of writing a new code generator for the 'HC11, 'HC05's,
> 805x-series,
> >PIC, etc, since Hi-Tech already has a code generator for their compiler
> for
>
>
> No problem with that. But I thought the initial problem was testing a
> bunch
> of ISBC8020s? Where did all the other excess about other cpus come
> into that?
>
> >each of those. It would be a BIG job to do that for the Hendrix
compiler,
> >reduced though it is, since what's needed is a general enough compiler
> >that once I write a debug monitor based on some existing model I already
have
>
what this refers to is the fact that I've used neither small-C or the
Hi-Tech compiler, and before I wade into yet another quagmire, for this
specific job, unless it leads me into a new tool that I can use later. Back
when these older tools were developed, there was no standard for 'C' and the
K&R "proposal" was seldom adhered to enough to allow one to rely on it.
What interests me about the HI-Tech compiler is that the thing supports the
'HC11, HC05, PIC, and TMS320 family. That's sufficient capability to
warrant the effort of learning it. The small-C would take a lot of work,
particularly since it's not written in a dialect of 'C' that is familiar to
me. I do, by the way, have the Mix-C compiler and its CP/M based
antecedent. I just realize, unlike lots of other, for some of whom it's
perhaps not yet the case, that I'm getting close to full capacity,
memory-wise, and I really don't want to learn yet another odd-ball compiler.
I'd rather do the job in assembler <sigh>.
The Hi-tech compiler, if the documentation is to be believed, doesn't have a
code generator for the 8080 and 8085, BTW. It's a pretty decent
possibility, however, "less-than-perfect" this compiler may be, if it were
to be fit to generate a "solution" to my problem, I'd use it. It's on the
list, but I'm not ready to wander into the quagmire without an account to
which to bill the time, (yet). It's not that I need to have someone pay for
me to learn what I don't know, but I do need a motivation to start, and a
deadline makes the job get done. I haven't used one of these
8020-descendants for several years, but a debug monitor written in a dialect
that supports everything that I might soon use would serve as a motivator.
>
> I wouldn't know, I did did the later version for Z80 with TDL opcodes.
>
I have a bunch of TDL stuff, but have never used it myself.
>
> >know. It's not enough that the 8080 and Z80 are already supported,
> since
>
what for? There are native tools that are completely useable.
>
> Also 8088 and maybe later.
>
> >I'll only need to use the 8080, which, BTW, it's not obvious that the
> >Hi-Tech 'C' supports. As I said, if I'm going to wander into the
> quagmire,
>
>
> I avoid the quagmire and use asm.
>
> >the near future. I'm quite sure nobody is going to hire me to generate
> code
> >for the Z80 or 8080. I've been known to write code in assembler as
> well,
> >but haven't done anything for hire in about 10 years that has required
> Z80
> >or 8080 coding.
>
>
> While I understand the desire it's all outside the scope of the original
> problem to test and apparently use a bunch of 8085 multibus cards.
>
> Oh, Z80 is still out there as Z180, Z380 and Rabbit for embedded
> apps and CPU library cores in gate arrays.
>
I don't see that as a justification for paying attention to them. The 650x
core is out there too, only at 5-10 MIPS in a core and at about half that
pin-compatible version. The core is significantly smaller than the Z80
equivalent, though it's because it has fewer resources. Performance,
however, is considerably better. That might depend on how it's to be used,
however. The Rabbit is promising, but it's sole-sourced.
>
> Allison
>
>
>
Received on Mon Oct 30 2000 - 21:31:40 GMT