On 9/6/2022 3:12 AM, Philipp Klaus Krause wrote:
> Am 06.09.22 um 10:59 schrieb Don Y:
>>
>> It could also be that many of the 8b devices are just not seeing much
>> market share (or have fallen out of production). How many 68xx devices
>> win designs nowadays? Does Zilog even make processors anymore? Etc.
>
> However, there are still plenty of people compiling code for the Z80 and SM83.
> But practically no one uses non-free compilers to do that.

I think much of that has to do with *when* those devices came on the market.
The choices for toolchains in the 68xx(x) and 808x/Z8x eras was barely more
than manufacturer supplied tools (e.g., under ISIS on the Intellec, RIO on the
ZDS, Versados on the EXORmacs, etc.). Recall PCs only came into being
in the early 80's; CP/M boxen being more common for nonproprietary platforms.
I didn't use PC-hosted tools until the NS32K -- and even those weren't
actually hosted on an x86!

> Most use SDCC either
> directly or via the z88dk fork. A few use zcc or ack. All of these are free, so
> not covered by the question that started the thread.

I'm sure every device I designed is still using the toolchain that I selected
at the time -- hence my comment of "inertia" in my initial post in this thread.
There are a fair number of products that have very long lifetimes where the
cost of making a significant change (i.e., complete redesign) drags in so
many externalities that it becomes prohibitive. "If it ain't broke, don't
fix it!" (I have some devices that are still being supported 30+ years
after the initial design)

ISTR the US military still uses 6502's in some of their armaments. And I
know there was a radhard 8085 some time ago...

> It is mostly a retrocomputing / -gaming crowd. Since many of them are willing
> to try development snapshots, and report bugs, their use of SDCC helps a lot in
> spotting bugs in SDCC early, so they can be fixed before a release.

Most of the arcade pieces that I'm familiar with were developed in ASM
(though I have no idea what the design methodology was for consoles).

Often, the "OS" (more of an "executive") was tailored to a very low
overhead implementation that doesn't lend itself to use of HLLs
(e.g., a single stack so any multitasking has to ensure stack
protocol isn't violated across a task switch)

[There was also a lot of proprietary hardware to manipulate the video
out-of-band as the processors of that era couldn't update displays
as fast as they were refreshed!]

On 06/09/2022 12:41, Philipp Klaus Krause wrote:
> Am 06.09.22 um 11:09 schrieb David Brown:
>>
>> One important question, which I certainly can't answer myself, is
>> whether this is worth the effort.
>
> That clearly depends on many aspects. What is the higher goal? What are
> the available resources? IMO improving the free toolchain for 8-Bit
> devices is worth it at this time.
>

Fair enough. You have a far better idea of the users, of the effort
involved, and the developer commitment than I do.

>> […]How many of these users would switch toolchains, even if SDCC were
>> made hugely better than whatever they have now?  I'd expect almost
>> none, they'd stick to what they have - most would not even upgrade to
>> newer versions of the same tools that they already use.
>>
>> I would expect existing SDCC users to be more interested in upgrading,
>> and they would always be happy with better code generation.  But I do
>> not imagine there are many /new/ users - either people starting
>> working on 8051 projects today, or moving from commercial toolchains.
>
> Indeed there is a question of putting in effort to match the needs of
> different user groups, such as current SDCC users targetting µC, current
> SDCC retrocomputing and retrogaming, current users of non-free tools, etc.
> Naturally, SDCC developers do have an idea about the needs and wants of
> current SDCC users from the mailing lists, issue trackers, etc.
> On the other hand, such information was not readily available about
> users that currently use a non-free compiler for architectures supported
> by SDCC. Knowing how much overlap there is between what could be done
> for different user groups is already useful information. In particular
> improving the machine-independent optimizations and debug support is
> something that will benefit both current and potential new users.
>
>