C cross-compiler for 6800 (yes, you read correctly)

[CTH]

Hi All,

Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...

Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.

I'm hoping for something that'll run under DosBox at least - although I'm guessing that the 6800 was already way obsolete but the time PC/MSDOS emerged.

Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?

Thx
Chris.

[dp]

On Monday, February 10, 2014 5:49:47 AM UTC+2, CTH wrote:
> ....

> Another avenue might be whether the GNU 68HC1X compilers can be pressed
> into service - anyone tried this?

The HC11 has more registers and opcodes, code for it won't run on
the 6800. 6802 was 6800 compatible, I think 6801 also was but I am
not sure, never used it. I never used the 02 either but did clone/extend
a kit (D5) for the 6802 on a 6800.

I am not sure there has ever been a C compiler for the 6800, I'd be
surprised if there has been one really. Would have been quite useless
for those tiny systems anyway.
My programming started using pencil and paper to write the assembly
code, then manually assemble it using the processor manual then enter it
into my kit, debug and run :D . I think I can still read some 6800 object
code :D :D .

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Andrew Smallshaw]

On 2014-02-10, dp <d...@tgi-sci.com> wrote:
> On Monday, February 10, 2014 5:49:47 AM UTC+2, CTH wrote:
>> ....
>> Another avenue might be whether the GNU 68HC1X compilers can be pressed
>> into service - anyone tried this?
>
> The HC11 has more registers and opcodes, code for it won't run on
> the 6800. 6802 was 6800 compatible, I think 6801 also was but I am
> not sure, never used it. I never used the 02 either but did clone/extend
> a kit (D5) for the 6802 on a 6800.
>
> I am not sure there has ever been a C compiler for the 6800, I'd be
> surprised if there has been one really. Would have been quite useless
> for those tiny systems anyway.

ISTR there were minor differences between 6800/6802 and 6801/6803.
It was easy enough to write code that would run on either but you
had to watch out for the odd exceptions both ways. It was when
you got up to the 6809 and its derivatives that 68xx compatibility
completely went out of the window.

Returning to the OP's issue I have hazy memories of coming across
a Small-C derivative for the 6800. I probably have a copy of it
around somewhere but it'll suffer from all the limitations Small-C
always had - K&R syntax, no floating point, no structures, only
single dimensional arrays. Dave Dunfield's Micro-C targeted many
processors of that vintage too and ISTR the source is a free download
now. I know it targeted the 6809, can't remember about plain 6800,
but it was designed to be easy enough to write new back ends for
and the manual actually described what was needed in some detail.
That wasn't much more capable than Small-C but did at least support
multi-dimensional arrays.

I'll have a look around my hard drive and see if I can find anything.

--
Andrew Smallshaw
and...@sdf.lonestar.org

[John Devereux]

CTH <unid...@gmail.com> writes:

> Hi All,
>
> Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
> Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.
>
> I'm hoping for something that'll run under DosBox at least - although
> I'm guessing that the 6800 was already way obsolete but the time
> PC/MSDOS emerged.

I think the old (commercial) IAR HC11 compiler had option flags to
generate 6800 code (suppress the HC11 specific instructions).

> Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?
>
> Thx
> Chris.

--

John Devereux

[Tauno Voipio]

You're probably out of luck.

The 6800 (6801, 6802, 6803) is very tight on data handling
paths: there are two 8-bit accumulators (A and B) which must
be used for nearly all data moving. There are also two
16-bit registers, X and SP, but due to their special uses,
they are less usable. IMHO, compiling C for this architecture
is at least challenging.

The first 680x processor suited for running C is 6809. The
68(HC)1x are its successors.

--

Tauno Voipio

[Tom Gardner]

On 10/02/14 04:40, dp wrote:
> I am not sure there has ever been a C compiler for the 6800, I'd be
> surprised if there has been one really. Would have been quite useless
> for those tiny systems anyway.

Not at all.

The current atmega devices are equivalent to a 6800, except
they have a /less/ pleasant architectures for C programs.
Most people program them in C, using a cross compiler.

But in the early 80s cross-compilers were a luxury: most
people used *self-hosted* compilers.
The major "challenge" I found was that, on a CP/M-Z80
system with two floppies, there was barely enough space
for the compiler's symbol table.

[Boudewijn Dijkstra]

Op Mon, 10 Feb 2014 09:56:08 +0100 schreef Tauno Voipio
<tauno....@notused.fi.invalid>:

> On 10.2.14 05:49, CTH wrote:
>> Resurrecting an ancient project from the 80's:
>> http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>>
>> Googling has turned up a few links but most are for defunct OS's (eg
>> FLEX). Assemblers are still around as a last resort.
>>
>> I'm hoping for something that'll run under DosBox at least - although
>> I'm guessing that the 6800 was already way obsolete but the time
>> PC/MSDOS emerged.
>>
>> Another avenue might be whether the GNU 68HC1X compilers can be pressed
>> into service - anyone tried this?
>

> You're probably out of luck.
>
> The 6800 (6801, 6802, 6803) is very tight on data handling
> paths: there are two 8-bit accumulators (A and B) which must
> be used for nearly all data moving. There are also two
> 16-bit registers, X and SP, but due to their special uses,
> they are less usable. IMHO, compiling C for this architecture
> is at least challenging.

How is this different from the challenges of modern(!) STM8 processors?



--
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

[MK]

If you don't mind paying for it:

http://www.avocetsystems.com/

(No idea how good)

I never programmed 6802 or 6809 in anything other than assembler but we
did several 68HC11 projects in C.

BTW the 'hc11 is not a derivative of the '09, the '09 had additional
registers and lea (load effective address) instructions which never
appeared elsewhere.

Michael Kellett

[David Brown]

Bytecraft have compilers for 6805 and 6808, if that is any help (I am
not familiar with the 6800, so I don't know the details). Bytecraft
tools are not cheap, especially if this is just a hobby, but they do a
great job at a very difficult task. And I'm sure that if you email
Walter Banks at Bytecraft, he will give you helpful advice.

[David Brown]

On 10/02/14 11:05, Tom Gardner wrote:
> On 10/02/14 04:40, dp wrote:
>> I am not sure there has ever been a C compiler for the 6800, I'd be
>> surprised if there has been one really. Would have been quite useless
>> for those tiny systems anyway.
>
> Not at all.
>
> The current atmega devices are equivalent to a 6800, except
> they have a /less/ pleasant architectures for C programs.

The AVRs (including the Mega) are a world apart from these old 8-bit
accumulator-based designs. While they have a few C-unfriendly issues
(too few pointer registers, poor stack addressing modes), they are far
easier for C. There is a reason why there are several good AVR C
compilers available in a range of price categories.

> Most people program them in C, using a cross compiler.
>
> But in the early 80s cross-compilers were a luxury: most
> people used *self-hosted* compilers.
> The major "challenge" I found was that, on a CP/M-Z80
> system with two floppies, there was barely enough space
> for the compiler's symbol table.
>

Nobody self-hosted on a 6800.

[John Devereux]

David Brown <david...@hesbynett.no> writes:

> On 10/02/14 11:05, Tom Gardner wrote:
>> On 10/02/14 04:40, dp wrote:
>>> I am not sure there has ever been a C compiler for the 6800, I'd be
>>> surprised if there has been one really. Would have been quite useless
>>> for those tiny systems anyway.
>>
>> Not at all.
>>
>> The current atmega devices are equivalent to a 6800, except
>> they have a /less/ pleasant architectures for C programs.
>
> The AVRs (including the Mega) are a world apart from these old 8-bit
> accumulator-based designs. While they have a few C-unfriendly issues
> (too few pointer registers, poor stack addressing modes), they are far
> easier for C. There is a reason why there are several good AVR C
> compilers available in a range of price categories.

Killer for me was the separate code/data memory address spaces. #pragma
PROGMEM and so forth. Putting some constant structures in flash ended up
infecting most of the program with weird typedefs and special versions
of library functions everywhere.

I think in principle the compilers could have made all of this
invisible, but none of them did AFAIK.

CM3 is so much nicer now for most things.

>> Most people program them in C, using a cross compiler.
>>
>> But in the early 80s cross-compilers were a luxury: most
>> people used *self-hosted* compilers.
>> The major "challenge" I found was that, on a CP/M-Z80
>> system with two floppies, there was barely enough space
>> for the compiler's symbol table.
>>
>
> Nobody self-hosted on a 6800.
>

--

John Devereux

[Walter Banks]

David Brown wrote:

> On 10/02/14 04:49, CTH wrote:

> ? Hi All,
> ?
> ? Resurrecting an ancient project from the 80's:
> ? http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
> ?
> ? Googling has turned up a few links but most are for defunct OS's (eg
> ? FLEX). Assemblers are still around as a last resort.
> ?
> ? I'm hoping for something that'll run under DosBox at least - although
> ? I'm guessing that the 6800 was already way obsolete but the time
> ? PC/MSDOS emerged.
> ?
> ? Another avenue might be whether the GNU 68HC1X compilers can be
> ? pressed into service - anyone tried this?
> ?
> ? Thx Chris.
> ?

>
> Bytecraft have compilers for 6805 and 6808, if that is any help (I am
> not familiar with the 6800, so I don't know the details). Bytecraft
> tools are not cheap, especially if this is just a hobby, but they do a
> great job at a very difficult task. And I'm sure that if you email
> Walter Banks at Bytecraft, he will give you helpful advice.

As far as I know the only commercial C compiler for the 6800
was part of the HP development system no longer produced or
supported. This did indeed translate C into code that would run
on the 6800 and that is about all that could be said for it.

The 6800 was phased out before the availability of basic
compiler technology needed to produce an asm competitive
compiler for 6800. The 6800 evolved into 6811 and 6805. The
6805 is a 6800 with a single accumulator and different codings
for the ISA.

The 6805 was our first C compiler project. The code generated
for the 6805 will not run on a 6800.

Regards,

Walter Banks
Byte Craft Limited
http://bytecraft.com

[David Brown]

On 10/02/14 14:42, John Devereux wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> On 10/02/14 11:05, Tom Gardner wrote:
>>> On 10/02/14 04:40, dp wrote:
>>>> I am not sure there has ever been a C compiler for the 6800, I'd be
>>>> surprised if there has been one really. Would have been quite useless
>>>> for those tiny systems anyway.
>>>
>>> Not at all.
>>>
>>> The current atmega devices are equivalent to a 6800, except
>>> they have a /less/ pleasant architectures for C programs.
>>
>> The AVRs (including the Mega) are a world apart from these old 8-bit
>> accumulator-based designs. While they have a few C-unfriendly issues
>> (too few pointer registers, poor stack addressing modes), they are far
>> easier for C. There is a reason why there are several good AVR C
>> compilers available in a range of price categories.
>
> Killer for me was the separate code/data memory address spaces. #pragma
> PROGMEM and so forth. Putting some constant structures in flash ended up
> infecting most of the program with weird typedefs and special versions
> of library functions everywhere.
>

Yes, that's another serious C-unfriendly issue with the AVR - no doubts
there. But it's still /much/ better for C work than the 6800 or similar
architectures, which was my point here.

> I think in principle the compilers could have made all of this
> invisible, but none of them did AFAIK.

You can't make the memory spaces invisible to the programmer without a
lot of inefficiencies, as it requires fat pointers. Compiler
optimisations can perhaps reduce the overhead a bit, but it would still
be there. But if you are happy to pay the price of 24-bit pointers, gcc
obliges:

<http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html>


Imagecraft had a different idea (at least when I used their AVR
compiler, which was a long time ago) - they made "const" mean "flash".
That let you write most C code in a natural way, and const data got put
in flash. But it meant that converting a non-const pointer to a const
pointer would cause disaster, which was a bad idea.

>
> CM3 is so much nicer now for most things.

Indeed.

The msp430 is probably the smallest cpu the is /really/ C friendly.

[dp]

On Monday, February 10, 2014 12:05:22 PM UTC+2, Tom Gardner wrote:
> On 10/02/14 04:40, dp wrote:
> > I am not sure there has ever been a C compiler for the 6800, I'd be
> > surprised if there has been one really. Would have been quite useless
> > for those tiny systems anyway.
>
> Not at all.

Hah! Not to some extent may be, but I won't agree with the "at all" :).

> The current atmega devices are equivalent to a 6800, except
> they have a /less/ pleasant architectures for C programs.

I have only a vague idea of the register model of the atmega,
but:
-is it unable to add 8bits (not to speak of 16) to a 16-bit register?
-is it unable to access data relative to its sp so one has to
constantly do tsx/txs (6800 lingo) and be able to access things
only at an 8 bit fixed, unsigned offset from X after that?

It the answers to these are "yes" we are closer to your
"not at all" but still a long way from it - namely,6800 systems
regarded a 2K EPROM as a huge space for an embedded project.
It will take 20k to fit the equivalent C code using a C compiler - if
you are lucky and if the compilers have become better than
I expect them to be.

> But in the early 80s cross-compilers were a luxury: most
> people used *self-hosted* compilers.

On the 6809 under MDOS09 there was a pascal compiler. I played
with it for a few months - I was learning the trade then.
Man it was moaning and puffing with the floppies clicking the
head load/unload for half an hour for not that long pieces
of code :D :D . Was pretty good though (integer only), my main
gain was to understand the difference between high an low
level programming. Had enough time to think about it while
waiting for the compiler :D :D. Basically high level is
a good thing if the underlying architecture/register model is
dirty/inconvenient and hiding it makes the programmer more
efficient. I am glad I had the stomach to stay with architectures
I did not find ugly and inconvenient (like the hugely popular x86 was,
nowadays ARM which is not as ugly, just limiting). Cost me a fortune from
a consumer point of view but the feeling when you look 20+
years back and like what you see to a point you still want
to keep on building on it is good, I suppose it is irreplaceable.

[dp]

On Monday, February 10, 2014 1:42:33 PM UTC+2, MK wrote:
> ...

> BTW the 'hc11 is not a derivative of the '09, the '09 had additional
> registers and lea (load effective address) instructions which never
> appeared elsewhere.
>
> Michael Kellett

Yep, I was about to post something in that sense but turned out
I am not the only one here who remembers that :-).

I grew up on 6809 assembly, RASM09 / RLOAD were used a lot :).
In fact I can still run them on an emulated th9 machine in
a dps window, haven't done so for ages though
( http://tgi-sci.com/misc/sc09em.gif ).
Last year or so I undug my first ever CPU board (early 80-s,
done as a hobby project), here are its remnants (was 100% populated
back in the day): http://tgi-sci.com/misc/grany09.gif . Was running
MDOS09, it was the one I used to play with the pascal compiler
I mentioned elsewhere (along with other boards on that bus).

[John Devereux]

David Brown <david...@hesbynett.no> writes:

> On 10/02/14 14:42, John Devereux wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>>> On 10/02/14 11:05, Tom Gardner wrote:
>>>> On 10/02/14 04:40, dp wrote:
>>>>> I am not sure there has ever been a C compiler for the 6800, I'd be
>>>>> surprised if there has been one really. Would have been quite useless
>>>>> for those tiny systems anyway.
>>>>
>>>> Not at all.
>>>>
>>>> The current atmega devices are equivalent to a 6800, except
>>>> they have a /less/ pleasant architectures for C programs.
>>>
>>> The AVRs (including the Mega) are a world apart from these old 8-bit
>>> accumulator-based designs. While they have a few C-unfriendly issues
>>> (too few pointer registers, poor stack addressing modes), they are far
>>> easier for C. There is a reason why there are several good AVR C
>>> compilers available in a range of price categories.
>>
>> Killer for me was the separate code/data memory address spaces. #pragma
>> PROGMEM and so forth. Putting some constant structures in flash ended up
>> infecting most of the program with weird typedefs and special versions
>> of library functions everywhere.
>>
>
> Yes, that's another serious C-unfriendly issue with the AVR - no doubts
> there. But it's still /much/ better for C work than the 6800 or similar
> architectures, which was my point here.

Yes sorry, drifted off the point there. Actually would be fine for most
deeply embedded programs, I ran into trouble when trying to do GUIs with
big constant structures like fonts and menus.

>> I think in principle the compilers could have made all of this
>> invisible, but none of them did AFAIK.
>
> You can't make the memory spaces invisible to the programmer without a
> lot of inefficiencies, as it requires fat pointers. Compiler
> optimisations can perhaps reduce the overhead a bit, but it would still
> be there. But if you are happy to pay the price of 24-bit pointers, gcc
> obliges:
>
> <http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html>

Those must have come after I abandoned AVR for new
development. Inefficient as you say.

> Imagecraft had a different idea (at least when I used their AVR
> compiler, which was a long time ago) - they made "const" mean "flash".

I thought that was standard behaviour for embedded, e.g. I thought the
gcc toolchains put constants into a read-only segment that the link
script puts in flash.

> That let you write most C code in a natural way, and const data got put
> in flash. But it meant that converting a non-const pointer to a const
> pointer would cause disaster, which was a bad idea.

I admit I under-use "const".

>>
>> CM3 is so much nicer now for most things.
>
> Indeed.
>
> The msp430 is probably the smallest cpu the is /really/ C friendly.

Yes never tried it but would look into it if needed something really
small/low power. Everyone had nice things to say about it. I seem to
recall it did not have a proper gcc port when I would have been in a
position to use it last, so I went with ARM.

[...]


--

John Devereux

[Rich Webb]

On Mon, 10 Feb 2014 16:18:23 +0100, David Brown
<david...@hesbynett.no> wrote:

>Imagecraft had a different idea (at least when I used their AVR
>compiler, which was a long time ago) - they made "const" mean "flash".
>That let you write most C code in a natural way, and const data got put
>in flash. But it meant that converting a non-const pointer to a const
>pointer would cause disaster, which was a bad idea.

Imagecraft now uses "__flash" to indicate that an object is in the
AVR's program memory space, so the overloading of "const" (which was
handy but had pitfalls, as you point out) is no longer supported.
There are also additional library functions (e.g., char *cstrcat())
where the constant object is in flash.

[George Neuner]

On Mon, 10 Feb 2014 12:20:16 +0100, "Boudewijn Dijkstra"
<sp4mtr4p....@indes.com> wrote:


>> The 6800 (6801, 6802, 6803) is very tight on data handling
>> paths: there are two 8-bit accumulators (A and B) which must
>> be used for nearly all data moving. There are also two
>> 16-bit registers, X and SP, but due to their special uses,
>> they are less usable. IMHO, compiling C for this architecture
>> is at least challenging.
>
>How is this different from the challenges of modern(!) STM8 processors?

Or from the 6502 ? [which has several compilers].

George

[dp]

Was any of these any useful? I seriously doubt this has been the case
but I don't really know.

Dimiter

[Tim Wescott]

It may be more profitable to look for an assembler, particularly if you
want to be _really_ nostalgic.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[Tim Wescott]

I used their 68HC11 tool chain, over 20 years ago. I remember it as
being a fine product that got the job done superbly.

[Paul Rubin]

dp <d...@tgi-sci.com> writes:
>> Or from the 6502 ? [which has several compilers].
> Was any of these any useful? I seriously doubt this has been the case
> but I don't really know.

Yes, see for example http://www.cc65.org/ which was maintained til
recently. I wonder if it's feasible to retarget it to the 6800.

From http://oliverschmidt.github.io/cc65/ :

cc65 has C and runtime library support for many of the old 6502
machines, including

the following Commodore machines:
VIC20
C16/C116 and Plus/4
C64
C128
CBM 510 (aka P500)
the 600/700 family
newer PET machines (not 2001).
the Apple ][+ and successors.
the Atari 8 bit machines.
GEOS for the C64 and C128.
the Nintendo Entertainment System (NES).
the Supervision console.
the Oric Atmos.
the Lynx console.

The libraries are fairly portable, so creating a version for other 6502s
shouldn't be too much work.

[Tauno Voipio]

The 6502 is still more crippled than 6800, with its
8 bit stack pointer etc.

--

-TV

[Robert Wessel]

Although the zero-page indirect stuff could make up for a lot of that,
and using that for the C stack pointer would have been easier than
using 6800's SP or X.

[upsid...@downunder.com]

On Sun, 9 Feb 2014 20:40:45 -0800 (PST), dp <d...@tgi-sci.com> wrote:

>I am not sure there has ever been a C compiler for the 6800, I'd be
>surprised if there has been one really. Would have been quite useless
>for those tiny systems anyway.

In the 1970/80's the only usable high level languages were PL/M 80 for
Intel 8080/85 processors and marginally some Pascal implementations
for 6809.

In those days, the C-language was just a fringe issue in the
microprocessor world, but of course a big issue in the PDP-xx
minicomputer world.

[dp]

On Monday, February 10, 2014 11:48:04 PM UTC+2, upsid...@downunder.com wrote:
> On Sun, 9 Feb 2014 20:40:45 -0800 (PST), dp <d...@tgi-sci.com> wrote:
>
> >I am not sure there has ever been a C compiler for the 6800, I'd be
> >surprised if there has been one really. Would have been quite useless
> >for those tiny systems anyway.
>
> In the 1970/80's the only usable high level languages were PL/M 80 for
> Intel 8080/85 processors and marginally some Pascal implementations
> for 6809.

Herve Tireford (I think it was him) had written the BASICM compiler
for the 6809, it was a lot more usable than the Pascal compiler I
had under MDOS09.
In fact it was quite good, one could not wish a lot more from a high level
language targeted at embedded applications. The limitation was the
16 bit address space it had to live in of course, and it was a
severe limitation, but apart from that it was really good (as was
the guy who wrote it of course).

[Centexbel]

In article <1ca51f94-5177-4cec-b181-2bc61d6f9293
@googlegroups.com>, d...@tgi-sci.com says...

I used PL9 a nice one-pass compiler...


Philippe


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[David Brown]

I had heard something about that, but I have never used the newer
versions of the Imagecraft compiler (I moved to gcc as soon as it was
solid for the AVR. You can't fault the excellent support and
ease-of-use that you get from Imagecraft, but gcc is a much more
powerful compiler).

[David Brown]

The named address spaces are quite new (as they are new to the C
standards). You can use them as alternatives to the "progmem" macros
and attributes - when you specify exactly which flash bank you are
using, they are approximately as efficient (depending on exact
optimisation details). You can also use a more general pointer that
covers all of flash and ram - but you pay for the flexibility in code
time and space.

Although I haven't used them myself (I haven't used the AVR for a new
project for quite a while, and I don't change tools for existing
projects), I think they are a nice idea. They are about as good a
solution as it is possible to get when using an 8-bit architecture to
address up to 512 KB flash.

>
>> Imagecraft had a different idea (at least when I used their AVR
>> compiler, which was a long time ago) - they made "const" mean "flash".
>
> I thought that was standard behaviour for embedded, e.g. I thought the
> gcc toolchains put constants into a read-only segment that the link
> script puts in flash.

gcc (in cooperation with the linker and linker scripts) will put /some/
types of consts into flash, depending on the architecture. But in C it
is valid to write code like this:

extern size_t strlen(const char* s);
size_t foo(void) {
char a[] = "Hello, world!";
return strlen(a);
}

I.e., you can cast a pointer to a non-const into a pointer-to-const.
This means that the implementation of "strlen" here cannot assume
anything special about the placement of "s" - it could be in flash, and
it could be in ram. For most architectures, assembly instructions for
pointer-to-ram and pointer-to-flash operations are the same, so there is
no problem. But on the AVR (and PIC, 8051, COP8, and many other small
micros), the operations are different. To be consistent, the
compiler/library implementer must choose either "fat" pointers with
their extra overheads, or assume that all normal pointers are to ram.
Thus on the AVR, "const" data must be allocated to ram - there is no
other way to be efficient and consistent.

The compiler will then give you some other method of declaring that a
particular piece of data is explicitly put in flash - such as "progmem"
and friends, or "__flash" named address spaces. And you use similar
compiler extensions to access said data. This is usually worth the
effort for strings, tables, etc., but not for small constants.

For targets that have a single unified address space (arm, msp430, most
32-bit processors), it is usually easy for the compiler to allocate
const data to read-only memory.

>
>> That let you write most C code in a natural way, and const data got put
>> in flash. But it meant that converting a non-const pointer to a const
>> pointer would cause disaster, which was a bad idea.
>
> I admit I under-use "const".

You should learn to love it. Values that don't change should be made
const - it lets the compiler do more checking for errors, and sometimes
also leads to better optimisation. Where possible, use "static const".
In particular, prefer "static const int maxValue = 100;" over "#define
maxValue 100" - as long as your compiler is optimising, it will generate
as good code and will have better static error checking. (You can't
replace /all/ macros this way - but do it when you can.) And any
function that takes a pointer to data but does not change that data
should const-qualify the pointer - it helps spot mistakes and can lead
to better object code.

>>>
>>> CM3 is so much nicer now for most things.
>>
>> Indeed.
>>
>> The msp430 is probably the smallest cpu the is /really/ C friendly.
>
> Yes never tried it but would look into it if needed something really
> small/low power. Everyone had nice things to say about it. I seem to
> recall it did not have a proper gcc port when I would have been in a
> position to use it last, so I went with ARM.
>

The msp430 has had a usable gcc port for many years, but it was arguably
not "proper" - it was outside the main gcc tree, and for a while it was
a long way behind mainline gcc. But thanks mainly to the efforts of
Peter Bigot, it has been solid - I have used it for many years. And now
TI has paid Redhat to make msp430 gcc a full member of the mainline gcc,
and to provide a complete toolchain and library package. This new
version is now available in beta, with integration in CCS.

Still, it must be said that the msp430 is only really C-friendly with
the devices up to 64K total memory (flash + ram + peripherals) - data
access beyond 64K means using 20-bit registers and that means messy
compiler-specific stuff. (You can access normal code over more than 64K
- it is only when you use pointers that addresses above 64K get ugly.)

[David Brown]

The 6502 was a different beast entirely. It was also used for the Acorn
BBC Micros, which were immensely popular in schools and education in the
UK, and there were a fair number of development tools made for it. I
certainly know C and Pascal compilers were available, as well as Forth
(but I think that was interpreted rather than compiled).

[John Devereux]

David Brown <david...@hesbynett.no> writes:

> On 10/02/14 17:00, John Devereux wrote:

[...]


[...]

>> I admit I under-use "const".
>
> You should learn to love it. Values that don't change should be made
> const - it lets the compiler do more checking for errors, and sometimes
> also leads to better optimisation. Where possible, use "static const".
> In particular, prefer "static const int maxValue = 100;" over "#define
> maxValue 100" - as long as your compiler is optimising, it will generate
> as good code and will have better static error checking.
> (You can't replace /all/ macros this way - but do it when you can.)

Oh I do use it for that. Or for ints I often use enum.

> And any function that takes a pointer to data but does not change that
> data should const-qualify the pointer - it helps spot mistakes and can
> lead to better object code.

That is the bit I don't do yet.

>>>>
>>>> CM3 is so much nicer now for most things.
>>>
>>> Indeed.
>>>
>>> The msp430 is probably the smallest cpu the is /really/ C friendly.
>>
>> Yes never tried it but would look into it if needed something really
>> small/low power. Everyone had nice things to say about it. I seem to
>> recall it did not have a proper gcc port when I would have been in a
>> position to use it last, so I went with ARM.
>>
>
> The msp430 has had a usable gcc port for many years, but it was arguably
> not "proper" - it was outside the main gcc tree, and for a while it was
> a long way behind mainline gcc.

Yes that was my recollection, no slight intended to the author.

> But thanks mainly to the efforts of Peter Bigot, it has been solid - I
> have used it for many years. And now TI has paid Redhat to make
> msp430 gcc a full member of the mainline gcc, and to provide a
> complete toolchain and library package. This new version is now
> available in beta, with integration in CCS.

Yes, I noticed that when I checked my previous post. Better late than
never I suppose.

> Still, it must be said that the msp430 is only really C-friendly with
> the devices up to 64K total memory (flash + ram + peripherals) - data
> access beyond 64K means using 20-bit registers and that means messy
> compiler-specific stuff. (You can access normal code over more than 64K
> - it is only when you use pointers that addresses above 64K get ugly.)

Well that is OK *now* since I would likely only use something like that
MSP430 on tiny projects. Thanks for making me look at it again.


--

John Devereux

[David Brown]

On 11/02/14 11:20, John Devereux wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> On 10/02/14 17:00, John Devereux wrote:
>
> [...]
>
>
> [...]
>
>>> I admit I under-use "const".
>>
>> You should learn to love it. Values that don't change should be made
>> const - it lets the compiler do more checking for errors, and sometimes
>> also leads to better optimisation. Where possible, use "static const".
>> In particular, prefer "static const int maxValue = 100;" over "#define
>> maxValue 100" - as long as your compiler is optimising, it will generate
>> as good code and will have better static error checking.
>> (You can't replace /all/ macros this way - but do it when you can.)
>
> Oh I do use it for that. Or for ints I often use enum.

The best choice depends on the context, of course. But remember to make
your consts "static" in such cases - then the compiler doesn't have to
generate storage for them in most cases. (You probably already know
this, John, but there may others reading this who don't.)

>
>> And any function that takes a pointer to data but does not change that
>> data should const-qualify the pointer - it helps spot mistakes and can
>> lead to better object code.
>
> That is the bit I don't do yet.

It doesn't often make a big difference, but I think it helps make
function declarations a bit clearer.

We use the msp430 on a number of projects, but we are seeing a steady
move away from the msp430 and AVR towards Kinetis Cortex M4 devices.
One area we find the msp430 useful is for higher temperature systems -
there is a nice 150 C msp430 chip, which is a lot cheaper, smaller,
lower power and easier to use than most alternatives at that temperature.

[Grant Edwards]

On 2014-02-11, David Brown <david...@hesbynett.no> wrote:

>>> The msp430 is probably the smallest cpu the is /really/ C friendly.
>>
>> Yes never tried it but would look into it if needed something really
>> small/low power. Everyone had nice things to say about it. I seem to
>> recall it did not have a proper gcc port when I would have been in a
>> position to use it last, so I went with ARM.
>
> The msp430 has had a usable gcc port for many years, but it was arguably
> not "proper" - it was outside the main gcc tree, and for a while it was
> a long way behind mainline gcc.

While "unofficial" it was solid and worked great for many of us who
used it without problems for years.

> But thanks mainly to the efforts of Peter Bigot, it has been solid -
> I have used it for many years. And now TI has paid Redhat to make
> msp430 gcc a full member of the mainline gcc, and to provide a
> complete toolchain and library package. This new version is now
> available in beta, with integration in CCS.
>
> Still, it must be said that the msp430 is only really C-friendly with
> the devices up to 64K total memory (flash + ram + peripherals) - data
> access beyond 64K means using 20-bit registers and that means messy
> compiler-specific stuff. (You can access normal code over more than 64K
> - it is only when you use pointers that addresses above 64K get ugly.)

I've never tried to use the 20-bit versions of the MSP430, but I
always felt that if 16-bit pointers and 64KB of address space wasn't
enough it was time to look at small ARM parts...

--
Grant Edwards grant.b.edwards Yow! ... I don't like FRANK
at SINATRA or his CHILDREN.
gmail.com

[Frank Miles]

On Tue, 11 Feb 2014 10:20:59 +0000, John Devereux wrote:

[snip]

> Well that is OK *now* since I would likely only use something like that
> MSP430 on tiny projects. Thanks for making me look at it again.

Its niche is made smaller by the restricted power supply (voltage) limits:
it doesn't quite work with a rechargeable lithium battery supply. If I
have to put in a regulator, one of the ARM variants offers more capabilities.
At the low end the AtMegas (and other 8-bitters) can handle the voltages.

[Paul Rubin]

Frank Miles <f...@u.washington.edu> writes:
>> MSP430 on tiny projects. ...>

> Its niche is made smaller by the restricted power supply (voltage) limits:
> it doesn't quite work with a rechargeable lithium battery supply.

There are a bunch of different models including some that go as low as
0.9 volts and use extremely little power. There are also some with
non-volatile (FRAM) memory, which I think is still close to unique. I
do think the architecture has gotten uncomfortably squeezed between ARM
and 8-bitters.

[George Neuner]

On Mon, 10 Feb 2014 10:18:18 -0800 (PST), dp <d...@tgi-sci.com> wrote:

>Was any of [6502 C compilers] any useful? I seriously doubt this

>has been the case but I don't really know.
>
>Dimiter

Back in the day I used Manx Aztec C - which was commercial - on Apple
and Commodore. It supported code overlays and had both native and
p-code compilers. You could link native code and p-code functions
together to balance executable size vs speed.

The 6502 native compiler produced pretty good code given the
limitations of the CPU and the p-code interpreter was heavily
optimized so p-code wasn't particularly slow either.

Only real caveat was compiling on floppies was painful. I was very
thankful to finally get hard disks.


Manx produced a whole family of 6502, 8080, z80 and 8086 compilers.
They are no longer supported but many of them still are available
here:
http://www.aztecmuseum.ca/compilers.htm#applenative


George

[George Neuner]

And ZP pseudo registers.

George

[George Neuner]

On Tue, 11 Feb 2014 15:29:19 -0500, George Neuner
<gneu...@comcast.net> wrote:

>Manx produced a whole family of 6502, 8080, z80 and 8086 compilers.
>They are no longer supported but many of them still are available
>here:
>http://www.aztecmuseum.ca/compilers.htm#applenative

and 68K.

>George

[Grant Edwards]

On 2014-02-11, Paul Rubin <no.e...@nospam.invalid> wrote:
> Frank Miles <f...@u.washington.edu> writes:
>>> MSP430 on tiny projects. ...>
>> Its niche is made smaller by the restricted power supply (voltage) limits:
>> it doesn't quite work with a rechargeable lithium battery supply.
>
> There are a bunch of different models including some that go as low as
> 0.9 volts and use extremely little power.

And after looking at the code generated for MSP430 by GCC for several
years. Then I started working the AVR parts and looking at the code
generated by C compilers gave me nightmares. I still shudder when I
think about AVR ISRs that use pointers. An ISR that was 3-5
instructions on a '430 would be 20-30 instructions on an AVR...

--
Grant Edwards grant.b.edwards Yow! I want to read my new
at poem about pork brains and
gmail.com outer space ...

[dp]

On Tuesday, February 11, 2014 10:29:19 PM UTC+2, George Neuner wrote:
> ...

>
> Only real caveat was compiling on floppies was painful. I was very
> thankful to finally get hard disks.

Hah, you might have been somewhat relieved back then if you knew
there were worse situations than yours.
I never used an Apple, but I had friends here who did. There was
a Bulgarian clone of the Apple II - which was a fair equivalent - and
there were the floppies also cloned which I have been told were even
worse than the original Apple ones :D . Had a plastic disk with an
engraved spiral to do head positioning, I never saw these things
work twice in a row without some major error :D :D :D .
In comparison to these even the hugely unreliable 8" clones of some
Shugart model I had were rock stable :D . [These taught me to always
have at least 3 disks with the latest version; it could (and did) happen
while backing up one floppy to another the original one to get unreadable
and the second one still mostly blank.... I had learned how and where
to press the head during retries to read a problematic sector, sewing
files together from physical dumps of 128 byte sectors was a trivial
exercise :D . Before too long I moved things to 5" and later to 3.5"
floppies and things got much much better.]

[Dombo]

Op 10-Feb-14 19:18, dp schreef:

I played a bit with CC65, which supports a subset of ANSI C89 (e.g. no
floating point). The code it generates is quite different from what a
competent 6502 assembly programmer would write. Having only one 8-bit
accumulator, two 8-bit index registers and a 256 byte stack to work with
makes 6502 a rather difficult target for a C compiler I guess. IMO C
compilers for the 6502 are not very useful if you just want to reuse
some C code not specifically written for this target. It might be
somewhat useful if for some reason you have to use a 6502, have memory
and performance to spare, don't feel like writing 6502 assembly code but
are willing to write C code specifically for this target. I feel pretty
much the same way about C compilers 8-bit AVR's, though for that target
the GCC compiler can produce quite reasonable code if you keep the
limitations of the 8-bit AVR in mind.

[Nick Leverton]

In article <ldaefa$si6$1...@dont-email.me>,

David Brown <david...@hesbynett.no> wrote:
>On 10/02/14 11:05, Tom Gardner wrote:
>

>> But in the early 80s cross-compilers were a luxury: most
>> people used *self-hosted* compilers.
>> The major "challenge" I found was that, on a CP/M-Z80
>> system with two floppies, there was barely enough space
>> for the compiler's symbol table.
>
>Nobody self-hosted on a 6800.

Does the Motorola Exorciser not qualify ? ISTR it was built with 6800s.

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

[dp]

On Wednesday, February 12, 2014 1:04:20 AM UTC+2, Nick Leverton wrote:
> In article <ldaefa$si6$1...@dont-email.me>,
> David Brown <david...@hesbynett.no> wrote:
> >On 10/02/14 11:05, Tom Gardner wrote:
> >
> >> But in the early 80s cross-compilers were a luxury: most
> >> people used *self-hosted* compilers.
> >> The major "challenge" I found was that, on a CP/M-Z80
> >> system with two floppies, there was barely enough space
> >> for the compiler's symbol table.
> >
> >Nobody self-hosted on a 6800.
>
> Does the Motorola Exorciser not qualify ? ISTR it was built with 6800s.

I believe this was about a C compiler, I don't think there ever
was one for MDOS and/or for MDOS09.
Then there was the Exorset also, it ran a version of MDOS09 called XDOS.
And there were numerous systems built to run MDOS and MDOS09, mine
included - which mostly took some patches to the MDOS code and
(at least for mine 2 machines) writing the firmware, the monitor at
$f000-$fbff and the disk eprom at $e800-$efff.

The usable programming tools were called RASM (6800 relocatable assembler),
RASM09 (same but for the 6809) and RLOAD (the linker for the above two).

The text editor took an Exorterm terminal, emulating that to a sufficient
extent so the editor would run using the terminal board I had built
was my first larger piece of code :-).

[CTH]

On Monday, February 10, 2014 3:40:45 PM UTC+11, dp wrote:
> On Monday, February 10, 2014 5:49:47 AM UTC+2, CTH wrote:
>
> > ....

>
> > Another avenue might be whether the GNU 68HC1X compilers can be pressed
>
> > into service - anyone tried this?
>
>
>

> The HC11 has more registers and opcodes, code for it won't run on
>
> the 6800. 6802 was 6800 compatible, I think 6801 also was but I am
>
> not sure, never used it. I never used the 02 either but did clone/extend
>
> a kit (D5) for the 6802 on a 6800.

>
>
>
> I am not sure there has ever been a C compiler for the 6800, I'd be
>
> surprised if there has been one really. Would have been quite useless
>
> for those tiny systems anyway.
>

> My programming started using pencil and paper to write the assembly
>
> code, then manually assemble it using the processor manual then enter it
>
> into my kit, debug and run :D . I think I can still read some 6800 object
>
> code :D :D .

>
>
>
> Dimiter
>
>
>
> ------------------------------------------------------
>
> Dimiter Popoff, TGI http://www.tgi-sci.com
>
> ------------------------------------------------------
>
> http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

This particular kit has a CHIPOS interpreter in EPROM so it can be programmed that way.

In the 80s I managed to get it to receive (bit-banged) MIDI from a Yamaha DX7 by assembling in exactly the same way you describe!

Cheers,
Chris.

[CTH]

On Monday, February 10, 2014 4:12:49 PM UTC+11, Andrew Smallshaw wrote:

> On 2014-02-10, dp wrote:
>
> > On Monday, February 10, 2014 5:49:47 AM UTC+2, CTH wrote:
>
> >> ....
>
> >> Another avenue might be whether the GNU 68HC1X compilers can be pressed
>
> >> into service - anyone tried this?
>
> >
>
> > The HC11 has more registers and opcodes, code for it won't run on
>
> > the 6800. 6802 was 6800 compatible, I think 6801 also was but I am
>
> > not sure, never used it. I never used the 02 either but did clone/extend
>
> > a kit (D5) for the 6802 on a 6800.
>
> >
>
> > I am not sure there has ever been a C compiler for the 6800, I'd be
>
> > surprised if there has been one really. Would have been quite useless
>
> > for those tiny systems anyway.
>
>
>

> ISTR there were minor differences between 6800/6802 and 6801/6803.
>
> It was easy enough to write code that would run on either but you
>
> had to watch out for the odd exceptions both ways. It was when
>
> you got up to the 6809 and its derivatives that 68xx compatibility
>
> completely went out of the window.
>
>
>
> Returning to the OP's issue I have hazy memories of coming across
>
> a Small-C derivative for the 6800. I probably have a copy of it
>
> around somewhere but it'll suffer from all the limitations Small-C
>
> always had - K&R syntax, no floating point, no structures, only
>
> single dimensional arrays. Dave Dunfield's Micro-C targeted many
>
> processors of that vintage too and ISTR the source is a free download
>
> now. I know it targeted the 6809, can't remember about plain 6800,
>
> but it was designed to be easy enough to write new back ends for
>
> and the manual actually described what was needed in some detail.
>
> That wasn't much more capable than Small-C but did at least support
>
> multi-dimensional arrays.
>
>
>
> I'll have a look around my hard drive and see if I can find anything.
>
>
>
> --
>
> Andrew Smallshaw
>
[snip]

I strongly suspected when I posted the original question that it'd be a long shot.

I appreciate your taking the time to look into it.

Cheers,
Chris.

[CTH]

On Monday, February 10, 2014 7:20:03 PM UTC+11, John Devereux wrote:

> CTH writes:
>
>
>
> > Hi All,
>
> >
>
> > Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
> >
>
> > Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.
>
> >
>
> > I'm hoping for something that'll run under DosBox at least - although
>
> > I'm guessing that the 6800 was already way obsolete but the time
>
> > PC/MSDOS emerged.
>
>
>

> I think the old (commercial) IAR HC11 compiler had option flags to
>
> generate 6800 code (suppress the HC11 specific instructions).

>
>
>
> > Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?
>
> >
>

> > Thx
>
> > Chris.
>
>
>
> --
>
>
>
> John Devereux

Thanks John, I'll look into it.

Cheers,
Chris.

[CTH]

On Monday, February 10, 2014 10:45:55 PM UTC+11, David Brown wrote:

> On 10/02/14 04:49, CTH wrote:
>
> > Hi All,
>
> >
>
> > Resurrecting an ancient project from the 80's:
>
> > http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
> >
>
> > Googling has turned up a few links but most are for defunct OS's (eg
>
> > FLEX). Assemblers are still around as a last resort.
>
> >
>
> > I'm hoping for something that'll run under DosBox at least - although
>
> > I'm guessing that the 6800 was already way obsolete but the time
>
> > PC/MSDOS emerged.
>
> >
>

> > Another avenue might be whether the GNU 68HC1X compilers can be
>
> > pressed into service - anyone tried this?
>
> >
>
> > Thx Chris.
>
> >
>
>
>

> Bytecraft have compilers for 6805 and 6808, if that is any help (I am
>
> not familiar with the 6800, so I don't know the details). Bytecraft
>
> tools are not cheap, especially if this is just a hobby, but they do a
>
> great job at a very difficult task. And I'm sure that if you email
>
> Walter Banks at Bytecraft, he will give you helpful advice.

Thanks David, if all other avenues fail this might be a practical last resort.

Cheers,
Chris

[CTH]

On Tuesday, February 11, 2014 12:48:34 AM UTC+11, Walter Banks wrote:
> David Brown wrote:
>
>
>
> > On 10/02/14 04:49, CTH wrote:
>

> > ? Hi All,
>
> > ?
>
> > ? Resurrecting an ancient project from the 80's:
>
> > ? http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
> > ?
>
> > ? Googling has turned up a few links but most are for defunct OS's (eg
>
> > ? FLEX). Assemblers are still around as a last resort.
>
> > ?
>
> > ? I'm hoping for something that'll run under DosBox at least - although
>
> > ? I'm guessing that the 6800 was already way obsolete but the time
>
> > ? PC/MSDOS emerged.
>
> > ?
>
> > ? Another avenue might be whether the GNU 68HC1X compilers can be
>
> > ? pressed into service - anyone tried this?
>
> > ?
>
> > ? Thx Chris.
>
> > ?

>
> >
>
> > Bytecraft have compilers for 6805 and 6808, if that is any help (I am
>
> > not familiar with the 6800, so I don't know the details). Bytecraft
>
> > tools are not cheap, especially if this is just a hobby, but they do a
>
> > great job at a very difficult task. And I'm sure that if you email
>
> > Walter Banks at Bytecraft, he will give you helpful advice.
>
>
>

> As far as I know the only commercial C compiler for the 6800
>
> was part of the HP development system no longer produced or
>
> supported. This did indeed translate C into code that would run
>
> on the 6800 and that is about all that could be said for it.
>
>
>
> The 6800 was phased out before the availability of basic
>
> compiler technology needed to produce an asm competitive
>
> compiler for 6800. The 6800 evolved into 6811 and 6805. The
>
> 6805 is a 6800 with a single accumulator and different codings
>
> for the ISA.
>
>
>
> The 6805 was our first C compiler project. The code generated
>
> for the 6805 will not run on a 6800.
>
>
>
> Regards,
>
>
>
> Walter Banks
>
> Byte Craft Limited
>
> http://bytecraft.com

Hi Walter. I did manage to turn up links that referenced the HP system you mention.

In reality, I suspected as much regarding your comments concerning availability of compilers in relation to the design-life of the 6800.

Thought it was worth a try...

Cheers,
Chris.

[CTH]

On Tuesday, February 11, 2014 6:23:54 AM UTC+11, Tim Wescott wrote:
> On Sun, 09 Feb 2014 19:49:47 -0800, CTH wrote:
>
>
>
> > Hi All,

>
> >
>
> > Resurrecting an ancient project from the 80's:
>

> > http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
> >
>

> > Googling has turned up a few links but most are for defunct OS's (eg
>

> > FLEX). Assemblers are still around as a last resort.
>
> >
>

> > I'm hoping for something that'll run under DosBox at least - although
>

> > I'm guessing that the 6800 was already way obsolete but the time
>

> > PC/MSDOS emerged.
>
> >
>
> > Another avenue might be whether the GNU 68HC1X compilers can be pressed

>
> > into service - anyone tried this?
>
> >
>

> > Thx Chris.
>
>
>
> It may be more profitable to look for an assembler, particularly if you
>
> want to be _really_ nostalgic.
>
>
>
> --
>
>
>
> Tim Wescott
>
> Wescott Design Services
>
> http://www.wescottdesign.com

Hi Tim, I already have a couple of those ;-). They won't run in any cmd windows on modern Windows, but that's what DosBox is for (they're fine there).

It's a promising step that I can re-create the original 'Monitor' EPROM binary from a cleaned-up OCR of the printed asm listing in the scanned magazine article.

Cheers,
Chris.

[CTH]

On Tuesday, February 11, 2014 6:58:57 AM UTC+11, Paul Rubin wrote:

> dp writes:
>
> >> Or from the 6502 ? [which has several compilers].
>
> > Was any of these any useful? I seriously doubt this has been the case
>
> > but I don't really know.
>
>
>

> Yes, see for example http://www.cc65.org/ which was maintained til
>
> recently. I wonder if it's feasible to retarget it to the 6800.
>
>
>
> From http://oliverschmidt.github.io/cc65/ :
>
>
>
> cc65 has C and runtime library support for many of the old 6502
>
> machines, including
>
>
>
> the following Commodore machines:
>
> VIC20
>
> C16/C116 and Plus/4
>
> C64
>
> C128
>
> CBM 510 (aka P500)
>
> the 600/700 family
>
> newer PET machines (not 2001).
>
> the Apple ][+ and successors.
>
> the Atari 8 bit machines.
>
> GEOS for the C64 and C128.
>
> the Nintendo Entertainment System (NES).
>
> the Supervision console.
>
> the Oric Atmos.
>
> the Lynx console.
>
>
>
> The libraries are fairly portable, so creating a version for other 6502s
>
> shouldn't be too much work.

Thanks Paul, I'll look into this!

Cheers,
Chris.

[Walter Banks]

dp wrote:

> On Monday, February 10, 2014 5:49:47 AM UTC+2, CTH wrote:
> > ....

> > Another avenue might be whether the GNU 68HC1X compilers can be pressed
> > into service - anyone tried this?
>

> The HC11 has more registers and opcodes, code for it won't run on
> the 6800. 6802 was 6800 compatible, I think 6801 also was but I am
> not sure, never used it. I never used the 02 either but did clone/extend
> a kit (D5) for the 6802 on a 6800.
>
> I am not sure there has ever been a C compiler for the 6800, I'd be
> surprised if there has been one really. Would have been quite useless
> for those tiny systems anyway.

> My programming started using pencil and paper to write the assembly
> code, then manually assemble it using the processor manual then enter it
> into my kit, debug and run :D . I think I can still read some 6800 object
> code :D :D .

The 6802 and 6808 (no onboard page0 memory not the later 6808
with a different ISA) were both 6800 compatible. The essential
difference was it was much easier to interface to. Most of our 6800
projects were actually done with 6802's. The 6801 had some
differences and both 6800 and 6801 were true subsets of the 6811.

If I were wanting to do a quick implementation of a C compiler for
the 6800 I would probably start with a 6811 C compiler and strip out
the code generation of the super set instructions or replace them with
6800 macros to emulate the additional instructions.
--

[Tim Wescott]

Elsewhere in this tangle of sub-threads, Walter Banks mentions that the
6811 is a superset of the 6800. So if you can find a new 6811 assembler
you can just exercise a little bit of self-control, and use the 6800 part.

[WangoTango]

In article <87eh3b8...@devereux.me.uk>, jo...@devereux.me.uk says...

> CTH <unid...@gmail.com> writes:
>
> > Hi All,
> >
> > Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
> >
> > Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.
> >
> > I'm hoping for something that'll run under DosBox at least - although
> > I'm guessing that the 6800 was already way obsolete but the time
> > PC/MSDOS emerged.
>

> I think the old (commercial) IAR HC11 compiler had option flags to
> generate 6800 code (suppress the HC11 specific instructions).
>

> > Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?

The Introl tool chain for the 68HC11 could generate 6800 code also.

[dp]

On Wednesday, February 12, 2014 2:43:21 AM UTC+2, Walter Banks wrote:
> ...

> If I were wanting to do a quick implementation of a C compiler for
> the 6800 I would probably start with a 6811 C compiler and strip out
> the code generation of the super set instructions or replace them with
> 6800 macros to emulate the additional instructions.

Uhm, yes but would still be somewhat painful - emulating a CPU
on another one with fewer registers should be if not painful at
least inefficient (one has to maintain the extra regs somewhere
in system memory). My experience with emulation has been the other
way, I did a source level emulation of the CPU32 on power (which
is how my vpa started) and a binary emulation of the 6809 on
power again; having the extra registers was a true blessing :-).

But then since you have done C for the *6805* I suppose a
CPU being too small won't impress you much if at all :D.

[Walter Banks]

Lets put it all in one place.

I agree with care the 6811 assembler could be used although there are
some 6800 cross assemblers around..

The 6811 has a second index register (Y) , the 6811 could treat the
A and B registers as a single 16Bit D register. The 6800 didn't have
mul and divide instructions. The 6800 was missing most (maybe all)
of the 16 bit compare instructions. The 6811 had several additional
ways to use the index registers. Both the 6811 and 6800 instruction
set documentation is online in multiple places including the original
Motorola documentation.

I have just looked at both the 6800 and 6811 ISA documentation.
Earlier I said I would start with a 6811 C compiler to create a 6800
compiler. This too would probably be quite difficult before it would reliably
work.

w..

[CTH]

Thanks Tim, yes I saw that.

It's the 'self-control' part that might be a problem ;-)

Cheers,
Chris.

[dp]

On Wednesday, February 12, 2014 3:33:39 AM UTC+2, Walter Banks wrote:
>
> ... The 6800 was missing most (maybe all)

> of the 16 bit compare instructions.

I was sure the 6800 had cpx # (remember the skip2 macro?... :-) )
but I was unsure about direct and extended addressing modes...
Not remembering that felt too personal so I ran a try (using
my dps emulated exorciser th9 emulation); they are there alright.

http://tgi-sci.com/misc/cpx.gif .

IIRC cpx on the 6800 produced only the Z flag correctly though,
so it was not a true 16 bit compare.

ROFL, can you believe we would be sitting discussing the 6800
after all these years :D . I seem to get some fun out of it,
who would have thought. :D

[CTH]

On Wednesday, February 12, 2014 1:09:53 PM UTC+11, dp wrote:
> On Wednesday, February 12, 2014 3:33:39 AM UTC+2, Walter Banks wrote:
>
> >
>
> > ... The 6800 was missing most (maybe all)
>
> > of the 16 bit compare instructions.
>
>
>
> I was sure the 6800 had cpx # (remember the skip2 macro?... :-) )
>
> but I was unsure about direct and extended addressing modes...
>
> Not remembering that felt too personal so I ran a try (using
>
> my dps emulated exorciser th9 emulation); they are there alright.
>
>
>
> http://tgi-sci.com/misc/cpx.gif .
>
>
>
> IIRC cpx on the 6800 produced only the Z flag correctly though,
>
> so it was not a true 16 bit compare.
>
>
>
> ROFL, can you believe we would be sitting discussing the 6800
> after all these years :D .

I'm amazed at the response too!

>I seem to get some fun out of it, who would have thought. :D

That's what I thought when I found my old kit, and started going through all the archived info ;-)

Cheers,
Chris.

[Paul Rubin]

CTH <unid...@gmail.com> writes:
> That's what I thought when I found my old kit, and started going
> through all the archived info ;-)

Do I correctly understand that your 6800 box has 1k of rom and 2k of
ram? It's not so easy to tell from the description. I guess that is
comparable to some of today's 8-bitters that are routinely programmed in
C. Even still it seems more in the retro spirit to program that machine
directly in assembler, since it's so small.

[David Brown]

On 11/02/14 18:28, Grant Edwards wrote:
> On 2014-02-11, David Brown <david...@hesbynett.no> wrote:
>
>>>> The msp430 is probably the smallest cpu the is /really/ C friendly.
>>>
>>> Yes never tried it but would look into it if needed something really
>>> small/low power. Everyone had nice things to say about it. I seem to
>>> recall it did not have a proper gcc port when I would have been in a
>>> position to use it last, so I went with ARM.
>>
>> The msp430 has had a usable gcc port for many years, but it was arguably
>> not "proper" - it was outside the main gcc tree, and for a while it was
>> a long way behind mainline gcc.
>
> While "unofficial" it was solid and worked great for many of us who
> used it without problems for years.
>

Yes, I am a big user of the "unofficial" port. There was a period when
msp gcc was very much behind the state of the art - it was based on gcc
3.2.3 even though gcc was well into the 4.x line with a lot of new
capabilities. We moved more to AVR chips at that time - the gcc support
on the AVR's was not the only factor in that decision, of course. After
the new gcc 4 support solidified (again, mainly thanks to Peter Bigot,
but also due to many others over the years), I was happy again :-)

(I know that /you/ know the history here, and probably remember more
details than I do, but others might be interested.)

>> But thanks mainly to the efforts of Peter Bigot, it has been solid -
>> I have used it for many years. And now TI has paid Redhat to make
>> msp430 gcc a full member of the mainline gcc, and to provide a
>> complete toolchain and library package. This new version is now
>> available in beta, with integration in CCS.
>>
>> Still, it must be said that the msp430 is only really C-friendly with
>> the devices up to 64K total memory (flash + ram + peripherals) - data
>> access beyond 64K means using 20-bit registers and that means messy
>> compiler-specific stuff. (You can access normal code over more than 64K
>> - it is only when you use pointers that addresses above 64K get ugly.)
>
> I've never tried to use the 20-bit versions of the MSP430, but I
> always felt that if 16-bit pointers and 64KB of address space wasn't
> enough it was time to look at small ARM parts...
>

That's my opinion too. I have worked a bit on a project using a 120 KB
msp430, using CCS 3 (it was before gcc supported the larger memory
spaces), and it was a complication I could happily live without.

[David Brown]

On 11/02/14 22:10, Grant Edwards wrote:
> On 2014-02-11, Paul Rubin <no.e...@nospam.invalid> wrote:
>> Frank Miles <f...@u.washington.edu> writes:
>>>> MSP430 on tiny projects. ...>
>>> Its niche is made smaller by the restricted power supply (voltage) limits:
>>> it doesn't quite work with a rechargeable lithium battery supply.
>>
>> There are a bunch of different models including some that go as low as
>> 0.9 volts and use extremely little power.
>
> And after looking at the code generated for MSP430 by GCC for several
> years. Then I started working the AVR parts and looking at the code
> generated by C compilers gave me nightmares. I still shudder when I
> think about AVR ISRs that use pointers. An ISR that was 3-5
> instructions on a '430 would be 20-30 instructions on an AVR...
>

A key aim with interrupt routines, especially on chips with lots of
registers and no "load/save multiple register" instruction, is to avoid
(non-inlined) function calls - it makes a huge difference.


Have you ever used a COP8 microcontroller? The overhead in figuring out
which interrupt occurred, stacking the basic registers (even though
there are only three of them), and jumping to the real interrupt routine
was typically something like 40 instruction cycles. You had the same
again for the exit. And each instruction cycles was ten clock cycles,
with a 10 MHz maximum clock. So you have close to 0.1 ms overhead for
an interrupt - it makes the AVR's interrupts seem lightning fast.

Also note that the newer X Megas have DMA and an "event" system that
lets you do quite a bit of action without needing interrupts.

[David Brown]

I don't think sending an email would help you - the Walter Banks at
Bytecraft is the Walter Banks that has been posting in this thread, and
he doesn't have a 6800 compiler.

[Grant Edwards]

On 2014-02-12, David Brown <david...@hesbynett.no> wrote:
> On 11/02/14 22:10, Grant Edwards wrote:
>
>> And after looking at the code generated for MSP430 by GCC for several
>> years. Then I started working the AVR parts and looking at the code
>> generated by C compilers gave me nightmares. I still shudder when I
>> think about AVR ISRs that use pointers. An ISR that was 3-5
>> instructions on a '430 would be 20-30 instructions on an AVR...
>
> A key aim with interrupt routines, especially on chips with lots of
> registers and no "load/save multiple register" instruction, is to avoid
> (non-inlined) function calls - it makes a huge difference.
>
> Have you ever used a COP8 microcontroller?

I came close once, but managed to dodge that bullet. I remember
reading through the datasheet and manuals and then being quite
relieved that we decided to do something else (though I don't remember
what the "something else" was -- it may have been one of the
low-pin-count '430s).

> The overhead in figuring out which interrupt occurred, stacking the
> basic registers (even though there are only three of them), and
> jumping to the real interrupt routine was typically something like 40
> instruction cycles. You had the same again for the exit. And each
> instruction cycles was ten clock cycles, with a 10 MHz maximum clock.
> So you have close to 0.1 ms overhead for an interrupt - it makes the
> AVR's interrupts seem lightning fast.
>
> Also note that the newer X Megas have DMA and an "event" system that
> lets you do quite a bit of action without needing interrupts.

--
Grant Edwards grant.b.edwards Yow! Will this never-ending
at series of PLEASURABLE
gmail.com EVENTS never cease?

[tridac]

On 02/10/14 03:49, CTH wrote:
> Hi All,
>
> Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
> Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.
>
> I'm hoping for something that'll run under DosBox at least - although I'm guessing that the 6800 was already way obsolete but the time PC/MSDOS emerged.
>
> Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?
>
> Thx
> Chris.

You could look into web archives for Manx Software systems products. I had
the Manx C compiler running on an Apple 2 with 5Mb hard drive circa 1983/5.
Of course, that was for a 6502 target and was very slow, both in compilation
and because of the volume of code produced for even the smallest of
programs.

I would find a good 6800 Xasm and use that, or if you can stand it, one of
the Forth packages that were available at the time. 6800 asm is pretty
trivial
anyway and should be easy to learn and become fluent in...

Chris

--
** Remove the meaning of life to reply...

[Paul Rubin]

tridac <desi...@ceeq.org> writes:
> Manx C compiler ... was for a 6502 target

Not sure how this can help with a 6800.

> I would find a good 6800 Xasm and use that, or if you can stand it, one of
> the Forth packages that were available at the time.

Do you mean run Forth on the 6800? The computer in the OP's post had
just 2k or so of memory, which probably isn't enough.

[Walter Banks]

The National COP8 and Zilog Z8 both were bit serial cores. There
was a later version of the COP8 that was implemented with parallel
data paths.

It was a fun processor :) to write a C compiler for. In addition to
your comments all of the paging addressing complete with slightly
different calculations of page addressing for jmp's and calls. It has
three types of jumps, pc relative, within the current page and absolute
address. One two and three byte instructions. As jump targets
drifted over page edge addresses during optimization they needed
to change from one type to another impacting code in other pages
as well.

It is one processor I would not want to write anything but a trivial
application in assembler

The good news is it was quite low power at the time it was released.

Walter..

[Tim Wescott]

For me it's the RCA 1802 and the COSMAC Elf.

We couldn't afford better when I was growing up, but several months of
abject begging did get me a COSMAC Elf kit when I was growing up. I
think the most I ever did with it was run an RC servo, and jigger the
clock timing so that you could actually get stable graphics on a TV with
a color-burst crystal.

[lang...@fonz.dk]

Den mandag den 10. februar 2014 04.49.47 UTC+1 skrev CTH:
> Hi All,
>
>
>
> Resurrecting an ancient project from the 80's: http://www.mjbauer.biz/DREAM6800.htm simply for nostalgia's sake...
>
>
>
> Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.
>
>
>
> I'm hoping for something that'll run under DosBox at least - although I'm guessing that the 6800 was already way obsolete but the time PC/MSDOS emerged.
>
>
>
> Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?
>
>
>
> Thx
>
> Chris.

something here?: http://retro.co.za/6809/


-Lasse

[Walter Banks]

A few years ago (well quite a few years ago) I was at the RCA plant
in NJ and met the guy who hand taped out the Elf had his retirement
delayed a few months waiting for one of the voyagers to pass one
of the outer planets just in case he was needed. NASA one way
or another was paying to make sure he was available in case he
was needed. He like most engineers I know didn't know how
to do nothing for a few months.

The response to 6800 has been amazing on this thread

w..

[Grant Edwards]

On 2014-02-12, Walter Banks <wal...@bytecraft.com> wrote:
>
>> For me it's the RCA 1802 and the COSMAC Elf.
>>
>> We couldn't afford better when I was growing up, but several months
>> of abject begging did get me a COSMAC Elf kit when I was growing up.
>> I think the most I ever did with it was run an RC servo, and jigger
>> the clock timing so that you could actually get stable graphics on a
>> TV with a color-burst crystal.
>
> A few years ago (well quite a few years ago) I was at the RCA plant
> in NJ and met the guy who hand taped out the Elf had his retirement
> delayed a few months waiting for one of the voyagers to pass one of
> the outer planets just in case he was needed. NASA one way or another
> was paying to make sure he was available in case he was needed. He
> like most engineers I know didn't know how to do nothing for a few
> months.

I'm confused. The Elf was a homebrew personal computer project
presented in Popular Electronics. There were a couple small
third-party companies that offered Elf kits based on the design from
the magazine, but I can't believe Voyager had an Elf in it.

Or did this guy tape up the 1802 processor itself?

--
Grant Edwards grant.b.edwards Yow! Hold the MAYO & pass
at the COSMIC AWARENESS ...
gmail.com

[CTH]

Yes, I noticed ;-)

Cheers,
Chris.

[CTH]

On Wednesday, February 12, 2014 4:15:46 PM UTC+11, Paul Rubin wrote:

> CTH writes:
>
> > That's what I thought when I found my old kit, and started going
>
> > through all the archived info ;-)
>
>
>
> Do I correctly understand that your 6800 box has 1k of rom and 2k of
>
> ram? It's not so easy to tell from the description.

I built the 4k RAM expansion (on a home-made PCB) but otherwise yes, 1k EPROM, 300bd FSK cassette tape storage, hex keypad and 64 x 32 dot composite video display.

>I guess that is
>
> comparable to some of today's 8-bitters that are routinely programmed in
>
> C. Even still it seems more in the retro spirit to program that machine
>
> directly in assembler, since it's so small.

You are entirely correct, of course, but with time pressures etc C is more convenient - provided it's feasible!

All indications are that assembler is how i's going to be...

Cheers,
Chris.

[CTH]

I have vague memories of that. Also the SC/MP based kits - lots of toggel switches & LEDs (new tech for the era!). They pre-date mine by a few years.

Cheers
Chris.

[CTH]

Agreed!

Cheers,
Chris.

[CTH]

Thanks Lasse, this looks interesting!

Cheers,
Chris.

[Tim Wescott]

I assume that Walter meant the 1802. I'm pretty sure it was the COSMAC
1802, and that it was part of a family of inter-operable "COSMAC" parts,
many of which the Elf was built from. Hence the "COSMAC Elf".

I do remember it having the most frustrating instruction set -- it was
just two or three instructions short of being a really powerful machine.
On the other hand, you could pretty much look at the instruction set and
see the logic behind it. There probably weren't many transistors in
there.

[Robert Wessel]

While the 1802 has been used in a fair number of spacecraft, the
Voyagers would have been design frozen well before the 1802 was
available.

[Walter Banks]

Tim Wescott wrote:

> On Wed, 12 Feb 2014 23:29:53 +0000, Grant Edwards wrote:
>
> > On 2014-02-12, Walter Banks <wal...@bytecraft.com> wrote:
> >>
> >>> For me it's the RCA 1802 and the COSMAC Elf.
> >>>
> >>> We couldn't afford better when I was growing up, but several months of
> >>> abject begging did get me a COSMAC Elf kit when I was growing up.
> >>> I think the most I ever did with it was run an RC servo, and jigger
> >>> the clock timing so that you could actually get stable graphics on a
> >>> TV with a color-burst crystal.
> >>
> >> A few years ago (well quite a few years ago) I was at the RCA plant in
> >> NJ and met the guy who hand taped out the Elf had his retirement
> >> delayed a few months waiting for one of the voyagers to pass one of the
> >> outer planets just in case he was needed. NASA one way or another was
> >> paying to make sure he was available in case he was needed. He like
> >> most engineers I know didn't know how to do nothing for a few months.
> >
> > I'm confused. The Elf was a homebrew personal computer project
> > presented in Popular Electronics. There were a couple small third-party
> > companies that offered Elf kits based on the design from the magazine,
> > but I can't believe Voyager had an Elf in it.
> >
> > Or did this guy tape up the 1802 processor itself?
>
> I assume that Walter meant the 1802. I'm pretty sure it was the COSMAC
> 1802, and that it was part of a family of inter-operable "COSMAC" parts,
> many of which the Elf was built from. Hence the "COSMAC Elf".

He taped the processor for the 1802. Thanks for bailing me out
:)

Amazing when you think about it the kind of processing power that
used to be used for space or any application.

w..

[Grant Edwards]

On 2014-02-12, Tim Wescott <t...@seemywebsite.really> wrote:

> I do remember it having the most frustrating instruction set -- it was
> just two or three instructions short of being a really powerful machine.
> On the other hand, you could pretty much look at the instruction set and
> see the logic behind it. There probably weren't many transistors in
> there.

Yea, it was pretty odd compared to the the other processors I had
worked with at the time (8080, Z80, PDP-11). In one class we had
homework assignments to write assembly language programs for an 1802,
but we had no actual hardware to run them on -- at the time I remember
being told the 1802 was the only rad-hard microprocessor processor.
Many years later in grad school I ended up writing some assembly
language for a CDC Cyber 6600 mainframe, and it was oddly reminiscent
of the 1802: the only way to read/write memory was via
register-indirect addressing, and there was no real support for a call
stack. [At least that's how I remember it 25 years later.]

--
Grant

[George Neuner]

On Wed, 12 Feb 2014 16:20:52 +0000, tridac <desi...@ceeq.org> wrote:

>You could look into web archives for Manx Software systems products.

I posted a link to the archive in another message. But AFAIK, Manx
never had a 6800 compiler.

>I had the Manx C compiler running on an Apple 2 with 5Mb hard drive
>circa 1983/5. Of course, that was for a 6502 target and was very
>slow, both in compilation and because of the volume of code produced
>for even the smallest of programs.

Large code size was somewhat inevitable.

The Aztec 6502 native compiler actually was pretty good. C is defined
in such a way that it requires most integer operations to be 16-bit or
larger. It takes a lot of instructions to run a mostly 16-bit program
on an 8-bit CPU. [Hence the bytecode compiler.]

George

[upsid...@downunder.com]

On Wed, 12 Feb 2014 15:37:04 -0800 (PST), CTH <unid...@gmail.com>
wrote:

You have been searching for a C-compiler for several days, in that
time you would have manually written quite a lot of manual assembler,
especially, if the algorithm has been tested with some high level
language at some other platform (such as Windows/Linux).

Of course, doing manual assembly from existing code (such as FORTRAN,
Pascal, C) will typically produce quite inefficient code. If high
performance assembly code is needed, either code everything from
scratch in assembly or let a good optimizing compiler (if available)
do the job.

If your main interest is retroing, very few high level compilers were
available in the 1970's for the 8 bitters. The only I remember from
those days was the PL/M-80 for 8080/85. This is understandable, since
the Intel (and Zilog) architecture was quite awkward for assembly
programming. The 6800/6500 families were much more assembly friendly,
so these were programmed in assembly for quite a while.

[upsid...@downunder.com]

Nice machine with sixteen word wide (16 bit) cache :-)

[upsid...@downunder.com]

Why do you need a call stack ? Do you intend to play with recursion or
some other "modern" tricks ? :-) :-)

The 1802 had a sufficient number of registers that could be used as a
program counter, thus one register could be assigned for the main
program and one for each subroutine. The main program just switched to
an other register as program counter and after execution, the
subroutine returned control to the main program, by simply switching
the register to be used as the program counter.

[David Brown]

I once wrote a 20,000 line assembly program for the COP8, running on a
32K OTP chip. It was one of these projects that started small, then
needed an other feature, then another feature, then another, until the
result was a monster. At each stage, it was faster and cheaper to add
more to the existing system than to redesign it with a sane processor
choice. But by the end, bugs could take an hour to identify, then it
took days to find an extra spare byte of OTP, or spare bit of ram, in
order to fix it. Often re-arranging the order of files in the linker
script would make a big difference to the space, as certain operations
(jump tables and data tables) had to be within a 256-byte page, so you
got different padding for different ordering.

Add to that the big, expensive, and unreliable emulators - which then
died. So later versions were debugged by burning the program into the
OTP chips and testing them out.

So I too would not want to write anything but a trivial application in
assembler - or C - for these chips!

But they /were/ solid and reliable microcontrollers - I don't remember
any failures in the field, even in some quite nasty environments.

[Grant Edwards]

On 2014-02-13, upsid...@downunder.com <upsid...@downunder.com> wrote:
> On Thu, 13 Feb 2014 02:36:05 +0000 (UTC), Grant Edwards
><inv...@invalid.invalid> wrote:
>
>>On 2014-02-12, Tim Wescott <t...@seemywebsite.really> wrote:
>>
>>> I do remember it having the most frustrating instruction set -- it was
>>> just two or three instructions short of being a really powerful machine.
>>> On the other hand, you could pretty much look at the instruction set and
>>> see the logic behind it. There probably weren't many transistors in
>>> there.
>>
>>Yea, it was pretty odd compared to the the other processors I had
>>worked with at the time (8080, Z80, PDP-11).

[...]

>>Many years later in grad school I ended up writing some assembly
>>language for a CDC Cyber 6600 mainframe, and it was oddly reminiscent
>>of the 1802: the only way to read/write memory was via
>>register-indirect addressing, and there was no real support for a call
>>stack. [At least that's how I remember it 25 years later.]
>

> Why do you need a call stack? Do you intend to play with recursion or

> some other "modern" tricks? :-) :-)

Maybe not recursion so much as re-entrancy, but it's mostly a culture
shock situation. If everything you work with has hardware support for
a call stack, it's quite a jolt the first time you run across
something that doesn't have it. You never had to think about what to
do without one...

> The 1802 had a sufficient number of registers that could be used as a
> program counter, thus one register could be assigned for the main
> program and one for each subroutine. The main program just switched to
> an other register as program counter and after execution, the
> subroutine returned control to the main program, by simply switching
> the register to be used as the program counter.

Allocate half the register to one task and half to the other and you
have free, instant, co-routine support.

--
Grant Edwards grant.b.edwards Yow! BARBARA STANWYCK makes
at me nervous!!
gmail.com

[upsid...@downunder.com]

On Thu, 13 Feb 2014 15:23:54 +0000 (UTC), Grant Edwards

<inv...@invalid.invalid> wrote:

>On 2014-02-13, upsid...@downunder.com <upsid...@downunder.com> wrote:
>> On Thu, 13 Feb 2014 02:36:05 +0000 (UTC), Grant Edwards
>><inv...@invalid.invalid> wrote:
>>
>>>On 2014-02-12, Tim Wescott <t...@seemywebsite.really> wrote:
>>>
>>>> I do remember it having the most frustrating instruction set -- it was
>>>> just two or three instructions short of being a really powerful machine.
>>>> On the other hand, you could pretty much look at the instruction set and
>>>> see the logic behind it. There probably weren't many transistors in
>>>> there.
>>>
>>>Yea, it was pretty odd compared to the the other processors I had
>>>worked with at the time (8080, Z80, PDP-11).
>[...]
>>>Many years later in grad school I ended up writing some assembly
>>>language for a CDC Cyber 6600 mainframe, and it was oddly reminiscent
>>>of the 1802: the only way to read/write memory was via
>>>register-indirect addressing, and there was no real support for a call
>>>stack. [At least that's how I remember it 25 years later.]
>>
>> Why do you need a call stack? Do you intend to play with recursion or
>> some other "modern" tricks? :-) :-)
>
>Maybe not recursion so much as re-entrancy, but it's mostly a culture
>shock situation.

You need re-entrancy only if you are using a pre-emptive multitasking.
A small multitasker will require about 1-4 KiB of memory, so you would
not use it for a small system anyway.

>If everything you work with has hardware support for
>a call stack, it's quite a jolt the first time you run across
>something that doesn't have it. You never had to think about what to
>do without one...

I started my career in programming with DDP-516 with 16 KiW of memory
and return address stored at the subroutine entry address :-)

>> The 1802 had a sufficient number of registers that could be used as a
>> program counter, thus one register could be assigned for the main
>> program and one for each subroutine. The main program just switched to
>> an other register as program counter and after execution, the
>> subroutine returned control to the main program, by simply switching
>> the register to be used as the program counter.
>
>Allocate half the register to one task and half to the other and you
>have free, instant, co-routine support.

Anyone actually using coroutines for anything really usable ?

The only time I have seen it used for some real application is the
RSX-11 (PDP-11) run time library register save (and restore) code. The
return from a run time routine would have looked like any ordinary
library function, but in fact, the registers were restored in the
coroutine.

[dp]

On Thursday, February 13, 2014 5:23:54 PM UTC+2, Grant Edwards wrote:
> .... If everything you work with has hardware support for

> a call stack, it's quite a jolt the first time you run across
> something that doesn't have it. You never had to think about what to
> do without one...

Modern day architectures (e.g. power) do not have a hardware
stack pointer either.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Tom Gardner]

On 13/02/14 16:02, upsid...@downunder.com wrote:
> On Thu, 13 Feb 2014 15:23:54 +0000 (UTC), Grant Edwards

>> If everything you work with has hardware support for
>> a call stack, it's quite a jolt the first time you run across
>> something that doesn't have it. You never had to think about what to
>> do without one...
>
> I started my career in programming with DDP-516 with 16 KiW of memory
> and return address stored at the subroutine entry address :-)

I used one of those to cross-assemble 6800 code for my university project.
Paper tape being read at 1000cps would probably break modern 'elf'n'safety
laws.

But that was a modern machine. My first programming was on
an Elliott-803, which had an architectural max of 8192
39 bit words. Power of two bits in a word, or an even
number of bits - that's for the wimps :) Had a
groundbreaking Algol-60 compiler too, by CAR Hoare.

>>> The 1802 had a sufficient number of registers that could be used as a
>>> program counter, thus one register could be assigned for the main
>>> program and one for each subroutine. The main program just switched to
>>> an other register as program counter and after execution, the
>>> subroutine returned control to the main program, by simply switching
>>> the register to be used as the program counter.
>>
>> Allocate half the register to one task and half to the other and you
>> have free, instant, co-routine support.
>
> Anyone actually using coroutines for anything really usable ?

Yes.

In the early 80s a company I worked at had a homebrew executive
written in C for hard realtime control running on things like
PDP11s and Z80s and anything else that came along.

The principle control structures were effectively
co-routines (although some purists might disagree) that could
be used for cooperative multitasking.

I used it to control a life support machine coded as a series of
FSMs. The code was very easy to read and corresponded more-or-less
directly with the specification. The pseudocode was
forever {
waitfor(condition1, condition2, condition3)
if (condition1 || condirion3) doSomething()
if (condition2) doSomethingElse()
waitfor(condition4)
etc
}

The waitfor() caused the flow of control to "disappear down
the plughole" and allowed other "threads" to execute. When
another thread yield()ed and a condition was true, the "PC
reappeared" and execution continued after waitfor().

[Grant Edwards]

On 2014-02-13, upsid...@downunder.com <upsid...@downunder.com> wrote:
> On Thu, 13 Feb 2014 15:23:54 +0000 (UTC), Grant Edwards

>>> Why do you need a call stack? Do you intend to play with recursion or
>>> some other "modern" tricks? :-) :-)
>>
>>Maybe not recursion so much as re-entrancy, but it's mostly a culture
>>shock situation.
>
> You need re-entrancy only if you are using a pre-emptive multitasking.

Or interrupts. Which, I suppose is a degenerate form of multitasking.

> A small multitasker will require about 1-4 KiB of memory, so you would
> not use it for a small system anyway.

In embedded systems interrupts are widely used on systems with only a
few hundred bytes of RAM and a few KB of ROM.

> Anyone actually using coroutines for anything really usable?

Sure. Back in the early 80's I worked on firmware for a cellular
phone which used a Hitachi version of the Z80. The Z80 had two
complete registers banks, and a single instruction could switch
between them. The phone's firmware was designed as a pair of
coroutines: one for each physical register bank. It worked very
nicely. The next project (this time a cellular base station rather
than mobile), the processor we chose didn't have multiple register
banks, so we did a small multi-tasking kernel. It's a bit more
overhead, but much more flexible.

--
Grant Edwards grant.b.edwards Yow! Am I having fun yet?
at
gmail.com

[Paul Rubin]

upsid...@downunder.com writes:
> You need re-entrancy only if you are using a pre-emptive multitasking.
> A small multitasker will require about 1-4 KiB of memory, so you would
> not use it for a small system anyway.

Nah, normal interrupt handlers are a form of preemption and these issues
do arise in them.

> Anyone actually using coroutines for anything really usable ?

Sure, it's a perfectly good way to get rid of control inversion if
you have layers of processing of a data stream, for example:

http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

The GA144 Forth processor and its predecessors have a cute coroutine
switch instruction that simply swaps the top of the return stack with
the program counter. Each coroutine has to be aware of the registers
and data stack of the previous one, but the programs on those chips are
so small that this is manageable.

[Grant Edwards]

On 2014-02-13, Tom Gardner <spam...@blueyonder.co.uk> wrote:

>> Anyone actually using coroutines for anything really usable ?
>
> Yes.
>
> In the early 80s a company I worked at had a homebrew executive
> written in C for hard realtime control running on things like
> PDP11s and Z80s and anything else that came along.
>
> The principle control structures were effectively
> co-routines (although some purists might disagree) that could
> be used for cooperative multitasking.
>
> I used it to control a life support machine coded as a series of
> FSMs. The code was very easy to read and corresponded more-or-less
> directly with the specification. The pseudocode was
> forever {
> waitfor(condition1, condition2, condition3)
> if (condition1 || condirion3) doSomething()
> if (condition2) doSomethingElse()
> waitfor(condition4)
> etc
> }
>
> The waitfor() caused the flow of control to "disappear down
> the plughole" and allowed other "threads" to execute. When
> another thread yield()ed and a condition was true, the "PC
> reappeared" and execution continued after waitfor().

That sort of control flow is still widely used and I think is
generally referred to as "stackless threading". Here's a nice
"library" of macros that implementes it in C:

http://dunkels.com/adam/pt/

If you're using gcc (which supports label pointers) the implementation
is nice and clean and easy to understand. If not, it uses Duff's
Device (which has a bit more overhead and makes your head hurt the
first time you look at it).

--
Grant Edwards grant.b.edwards Yow! Where's the Coke
at machine? Tell me a joke!!
gmail.com

[Tauno Voipio]

On 13.2.14 20:05, Tom Gardner wrote:

> But that was a modern machine. My first programming was on
> an Elliott-803, which had an architectural max of 8192
> 39 bit words. Power of two bits in a word, or an even
> number of bits - that's for the wimps :) Had a
> groundbreaking Algol-60 compiler too, by CAR Hoare.

The Ellie had two instructions per word: 6 bits opcode,
13 bits address, B bit, 6 bits opcode and 13 bits of address.

The B bit gave a weird indexing / base operation: The result
of the left-hand memory operation was used to modify the
address part of the right-hand operation if the B bit was set.

The Elliott 803 used ferrite memory toroids as logic devices
and nickel-spiral delay lines for registers. Main machine cycle
was 288 us, with three-phase clock to pump the data in proper
direction through the ferrite-ring logic.

At least the bigger brother, 503, had 40 bits, with the last bit
as a parity bit not shown to the programmer.

There was also a assembler/copmiler (actually neither) called
Autocode.

--

Tauno Voipio

[Tim Wescott]

The 1802 was still popular for space applications into the 1990's. I
think you could still get it in silicon on sapphire into the 21'st
century.

If I recall correctly the reason the 1802 was rad-hard was just that the
sheer size of the features meant that one ionizing particle zipping
through the chip wasn't going to make much difference, where something
with itty bitty features could go awry if just one electron got knocked
out of place at the wrong time.

At least to my understanding, newer processors aren't really rad hard so
much as that people have figured out how to work around their rad
"softness".

[Tom Gardner]

The runtime I was referring to had conventional stacks
unlike protothreads; within a thread the code looked
and behaved as standard C code. I've looked at Dunkel's
protothreads and thought them a bit limiting: you'd have
to adapt a traditional coding style too much to work with
them.

The runtime wasn't pure C: it always had
a tiny bit of assembler to save/load (IIRC) the SP and PC and maybe
some machine specific registers. No big deal, and it made
everything else /so/ much simpler. Was setjmp/longjmp even
in the language in in 1980/1981?

[Tom Gardner]

On 13/02/14 19:33, Tim Wescott wrote:
> If I recall correctly the reason the 1802 was rad-hard was just that the
> sheer size of the features meant that one ionizing particle zipping
> through the chip wasn't going to make much difference, where something
> with itty bitty features could go awry if just one electron got knocked
> out of place at the wrong time.

I was under the impression that the sapphire substrate
formed a useful isolator, which therefore had Good Properties
w.r.t. radiation, in ways that I never bothered to understand.

[Tim Wescott]

That may be, but I doubt that the el-cheapo 1802 that came with my COSMAC
Elf was silicon-on-sapphire.

[upsid...@downunder.com]

On Thu, 13 Feb 2014 18:10:49 +0000 (UTC), Grant Edwards
<inv...@invalid.invalid> wrote:

>On 2014-02-13, upsid...@downunder.com <upsid...@downunder.com> wrote:
>> On Thu, 13 Feb 2014 15:23:54 +0000 (UTC), Grant Edwards
>
>>>> Why do you need a call stack? Do you intend to play with recursion or
>>>> some other "modern" tricks? :-) :-)
>>>
>>>Maybe not recursion so much as re-entrancy, but it's mostly a culture
>>>shock situation.
>>
>> You need re-entrancy only if you are using a pre-emptive multitasking.
>
>Or interrupts. Which, I suppose is a degenerate form of multitasking.

Many stackless machines had interrupts. In such machines, there were
of course severe restrictions what you could do in the ISR.

[David Brown]

On 13/02/14 17:28, dp wrote:
> On Thursday, February 13, 2014 5:23:54 PM UTC+2, Grant Edwards wrote:
>> .... If everything you work with has hardware support for
>> a call stack, it's quite a jolt the first time you run across
>> something that doesn't have it. You never had to think about what to
>> do without one...
>
> Modern day architectures (e.g. power) do not have a hardware
> stack pointer either.
>

(I know /you/ probably know this, but others are reading this thread.)

That's perhaps a matter of definition - as the PPC has all the
addressing modes needed to make a stack using any GPR, you could say it
has as many stack pointers as you want (assuming you never want more
than 31!).

It is common for RISC architectures not to have a dedicated stack
pointer as part of their ISA, simply because the same operations you
want on a stack are also useful for other structures, and therefore it
makes sense to make it a general operation. The choice of register for
the SP is then left up to the ABI (which is usually quite specific about
it).

Many modern RISC microcontrollers have some sort of alternative compact
instruction set (Thumb, VLE, etc.) which often force the use of a
specific stack pointer register for at least some instructions or
addressing modes (VLE on the PPC does not do that, IIRC).

But such architectures usually don't stack return addresses on a "call"
instruction - the return address is put in the "link register" and it is
up to the callee to store the old LR on the stack before using a "call"
by itself. The LR is thus a register dedicated to the top-of-stack (or,
if you like, it is a single entry hardware call stack).

[Tom Gardner]

Probably not, but IIRC SOI was available as an early option.

AvenetExpress will still sell you an 1802 for $131. But
judging from my recent experience, getting them to deliver
it may be a different matter :(

[Robert Wessel]

Not really any more than on machines *with* stacks. You just have to
save the state somewhere.

Consider S/360 and its descendents as an example. Interrupts stored
the old PSW (IP+CPU flags, basically), and (depending on the
interrupt) some information about the interrupt, all in fixed
locations in low core. The "new" PSW would typically disable the type
of interrupt (for example, you'd start the I/O interrupt handler with
I/O interrupts disabled), and each interrupt handler would have a bit
of reserved low core for storing regs, doing stuff, etc. If it needed
to do something more than trivial, the interrupt handler would have to
store the regs back in the interrupted task's state structure, and
then go off and establish the environment it needed to do the more
complex thing, and afterwards redispatch the interrupted task (or hand
control back to the dispatcher). But once you saved enough stuff to
get out of low core, you could re-enable interrupts again.

And that's no different than a machine with stacks - most machines
with a protected mode and stacks will actually switch to a protected
mode stack during an interrupt. But you almost always had better
ensure that the CPU doesn't take an interrupt of the same type while
on that protected mode stack, or the second interrupt will clobber the
stack entries of the first.