sdcc-user Mailing List for Small Device C Compiler (SDCC)

If you did build and "make install" sdcc (from trunk or source snapshots 
tarball) between the beginning of March, and today, this issue most 
likely affects you.

During my work on merging current upstream binutils into thr SDCC fork, 
I introduced a bug (https://sourceforge.net/p/sdcc/bugs/3972/). The bug 
resulted in "make install" installing some executables into 
/usr/local/bin that did not have the sd prefix the binaries from the 
SDCC binutils fork should have.

This resulted in some executables, in particular addr2line, readelf, 
strip, size, strings being installed in /usr/local, i.e. in the user's 
path that did not support the host binaries (sine they were compiled 
with support for SDCC targest only).

When the user attempted to e.g. do a "strip" of a host binary, 
/usr/local/bin/strip could be in the path and be used instead of the 
correct executable. Then, instead of the intended strip action on the 
host binary, the user would just get an error message "Unexpected 
character `\177' in asxxxx .rel file"

If you are affected by the issue, you will notice executables addr2line, 
readelf, strip, size, strings in /usr/local/bin with the same or similar 
creation timestamp as /usr/local/bin/sdcc. In tha case, please:

* Delete addr2line, readelf, strip, size, strings in /usr/local/bin
* Use an SDCC version from before March 2026 or later than today's 
revision 16451.

Philipp

Good afternoon!

Since C23 clarified the wording of the description of the generic 
selection feature, i.e. _Generic, originally introduced in C11, it is 
now obvious that SDCC's current implementation of generic selection 
deviates from the standard in the following ways:

SDCC currently ignores all qualifiers when comparing types in _Generic. 
The C standard does however require that:

"If the generic controlling operand is an assignment expression, the 
controlling type of the generic selection expression is the type of the 
assignment expression as if it had undergone an lvalue conversion, array 
to pointer conversion, or function to pointer conversion. Otherwise, the 
controlling type of the generic selection expression is the type 
designated by the type name."

I.e. the types in generic associations should not be touched, and our 
implementation (which does) cannot inspect qualifiers (such as 
const-ness) of pointee types, but should be able to.

Problems with default const-ness in SDCC

Addressing these issues did however reveal further deviations from 
standard compliance in SDCC's type system or type handling, namely:

Firstly, for historical reasons, ANSI and ISO C have always required 
string literals to be arrays of char rather than const char. In SDCC, 
string literals are arrays of const char, like in C++. Consequently, 
their type is considered different in the context of the standard 
compliant _Generic, which led to regression test failures.

Secondly, SDCC supports the named address space __code for some of its 
target architectures. Where this address space is read-only, SDCC 
implicitly makes objects therein const, which does superficially make 
sense, but interferes with _Generic-like type introspection. Whether the 
C standard combined with the Embedded C TR allows an address space 
qualifier to imply a const qualifier is very dubious and it is 
reasonable to presume that it does not. This, too, led to regression 
test failures with the repaired _Generic.

Proposed solution

For the sake of standard compliance, I would like to hereby suggest to 
make both, string literals and objects in __code, non-const by default, 
resolving the issues described above. To aid writing bug-free code, I 
would have SDCC emit a warning whenever an object in read-only __code 
space is not explicitly const, and also for pointers to such objects.

The command line options --fconst-str and --fconst-code would be added 
for use cases where precisely matching the behavior of earlier SDCC 
versions is desirable.

It seems desirable to resolve these issues for the upcoming 4.6.0 release.

Please let me know your opinions on the proposed solution.

Greetings,
Benedikt

Am 04.01.26 um 07:23 schrieb ず:
> I plan to first look at other processor backends to decide which one
> to take as a reference. MCS51 is my first candidate; would you
> recommend any other SDCC backend as a better starting point?

Yes. Have a look at m6502, hc08, maybe some others.

mcs51, ds390, pic14, pic16 still use the old register allocator, which I 
would not recommend for new SDCC targets, unless there are quite unusual 
requirements.

Philipp

Am 06.12.25 um 18:06 schrieb Hill, Krista:
> Hello folks,
>
> I'm looking about for support for the 6801 micro, which has some useful
> features over the MC6800. In particular the A and B accumulators to form
> the 16 bit D register. I see that there is support for the 68HC08 and
> S08 which are related.
>
> Please, I'd like to know if there is or ever was any  interest in the
> 6801 micro. Also, a vague outline of what it would take to get the SDCC
> to provide such support, would be appreciated.
>
> Thanks in advance,
> Krista

I'm also interested in SDCC support for MC6800. I've developed MC6800
ports for several C compilers:

- chibicc-6800-v1 (https://github.com/zu2/chibicc-6800-v1)
- ack-6800 (https://github.com/zu2/ack-6800)

The as6800 assembler from https://shop-pdp.net/ashtml/ seems adaptable
to sdas/as6800 with minor fixes, but the work is still in progress.

Since MC6800 lacks ABX/XGDX/PSHX/PULX (which MC6801 has), X register
tracking becomes very important. It also lacks SUBD, so 2-byte
compare/branch sequences need multiple branch instructions, which adds
overhead—but that is exactly what makes it rewarding. For the backend,

I plan to first look at other processor backends to decide which one
to take as a reference. MCS51 is my first candidate; would you
recommend any other SDCC backend as a better starting point?

-- 
zu2

Am 09.12.25 um 12:05 schrieb Alan Cox:
>  > Sorry, the 6801 is okay. But far from "extremely nice […] for C" or
>  > "better than pretty much anything". IMO, the STM8 is far better, and
>  > some of the Z80-derivatives with efficient stackpointer-relative
>  > addressing are also quite good, the HCS08 isn't that bad either (though
>  > its sp-relative adressing mode is less efficeint than zero-page
>  > addressing, which makes it worse than STM8 or those Z80-derivatives
>  > mentioned before).
> 
> I am looking at code density and performance numbers. It certainly beats 
> the Z80 derived stuff I've looked at (Rabbit, Z280) for most cases. STM8 
> I'm not really familiar with at it's a modern microcontroller not a 
> "real" CPU 8)

We have graphs at 
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/, 
which are meant to track SDCC progress/regress, but can be used to 
compare aechitectures. For current SDCC, I do see a real Rabbit 
advantage vs. Z80. In Coremark, the code sizes Z80:R3KA:STM8 roughly are 
18:13:12, in Dhrystone 9:8:7, in Whetstone 13:10:9, in stdcbench 28:23:19.

I'm looking forward to see how this will compare to MC6801 and R4K, once 
we support those.

Philipp

On Mon, 8 Dec 2025 22:42:38 +0100
Philipp Klaus Krause <pk...@sp...> wrote:

(Switching from my ancient email to current one as I've finally updated my
mailing list subscription)

> Am 08.12.25 um 18:42 schrieb al...@lx...:
> >> Having had a quick look at the architecture, I think SDCC is a good
> >> choice for a compiler targeting it. The instruction set, and adressing
> >> modes look ok, the 16-bit stack pointer and index register will be
quite
> >> helpful. It is kind of a typical architecture for an SDCC target - not
a
> >> great target for C, but not too bad either.
> >
> > It's an extremely nice machine for most C code generation as far as 8bit
> > processors go. It's probably better than pretty much anything except
6809
> > - certain beats the Z80 flat.
>
> Sorry, the 6801 is okay. But far from "extremely nice […] for C" or
> "better than pretty much anything". IMO, the STM8 is far better, and
> some of the Z80-derivatives with efficient stackpointer-relative
> addressing are also quite good, the HCS08 isn't that bad either (though
> its sp-relative adressing mode is less efficeint than zero-page
> addressing, which makes it worse than STM8 or those Z80-derivatives
> mentioned before).

I am looking at code density and performance numbers. It certainly beats
the Z80 derived stuff I've looked at (Rabbit, Z280) for most cases. STM8
I'm not really familiar with at it's a modern microcontroller not a "real"
CPU 8)

Pretty much every C operation can be done on n,X and that means you just
have D as the working value and never really do much register allocation or
cleverness. In theory you can do clever stuff for an 8bit counter working
on an 8bit value but that's about it.

> > Having written two 6801/3 compilers that isn't the case at all. You want
> > everything on the stack most of the time because indexed is faster and
> > more compact than extended. […]
>
> Thanks. That experience is certainly helpful for me to get a better idea
> of the MC6801.

The other things I can think of which are probably useful

Once you get to 6801/3 the X register becomes doubly useful. The obvious
usage is that it is whatever you were pointing at last. The second use case
is where you can generate something efficiently into X as an argument you
can PSHX faster and one byte shorter than PSHA/B. So for example fcc will
generate

             LDX _global
             PSHX
             LDX #1234
             PSHX

for function calls. PULX is also very handy for taking stuff back off the
stack on a return from a function. Classic 6800 this is horrible and fcc
6800 specific ABI has the called function doing the cleanups.
Constant loads can be optimized a lot of the time if you know the old A and
B values or half is zero as is common, or on raw 6800 if they are the same
- also common for -1. Fcc spends a certain amount of effort not just
turning  LDD #0 into CLRA CLRB but also generating stuff using TAB and TBA
when it makes sense, especially on 6800 itself that has no LDD so stuff
like LDA #0xFF TAB is shorter.

Useful tricks

6800:  PULX is TSX (if needed) LDX ,X  INS INS
All:  16bit negate is NEGA NEGB SBCA #0

There is stuff I didn't really get into with fcc because of space
constraints running on a 6803 itself

- Using A and B as two independent working values when possible (which is
rare, and it's hard to do ops between registers too)

- Using direct page values for "registers" other than using a word for the
upper half of the 32bit working value, and some scratch registers in
helpers. Unlike TMS7000 influenced targets or even 6502 there's not much
you can do directly with a direct page or register memory value that helps
except byte inc/dec (asm 680x regularly uses a direct page value for dec
and branching on loops)

I can imagine there are cases where you are pointer chasing in a loop that
a direct page "register" would pay off to avoid having to keep reloading
things through tsx and ldx n,x but that's beyond what my little compiler
can grok.

A modern vaguely smart cross compiler for 680x would be nice to have.

Alan

Am 08.12.25 um 18:42 schrieb al...@lx...:
>> Having had a quick look at the architecture, I think SDCC is a good
>> choice for a compiler targeting it. The instruction set, and adressing
>> modes look ok, the 16-bit stack pointer and index register will be quite
>> helpful. It is kind of a typical architecture for an SDCC target - not a
>> great target for C, but not too bad either.
> 
> It's an extremely nice machine for most C code generation as far as 8bit
> processors go. It's probably better than pretty much anything except 6809
> - certain beats the Z80 flat.

Sorry, the 6801 is okay. But far from "extremely nice […] for C" or 
"better than pretty much anything". IMO, the STM8 is far better, and 
some of the Z80-derivatives with efficient stackpointer-relative 
addressing are also quite good, the HCS08 isn't that bad either (though 
its sp-relative adressing mode is less efficeint than zero-page 
addressing, which makes it worse than STM8 or those Z80-derivatives 
mentioned before).

> 
> You do need to do good register tracking on the X register and also
> know how to dynamically calculate offsets from the current X register
> versus S at any point to make it work well. So for example you end up
> doing stuff like
> 
>     TSX
>     LDB #8
>     ABX
>     PSHX    ; push &x
>     LDD 4,X ; tracking live X so we don't keep reloading with TSX
> 
>> The main difficulty will likely be the lack of an efficient
>> stackpointer-relative addressing mode, so stack accesses would have to
>> use the index register - and there is only one index register, which
>> also needs to be used for pointer accesses. Thus, you'll probably want
>> local variables to not be on the stack by default (like for mos6502,
>> pdk, mcs51, hc08).
> 
> Having written two 6801/3 compilers that isn't the case at all. You want
> everything on the stack most of the time because indexed is faster and
> more compact than extended. […]

Thanks. That experience is certainly helpful for me to get a better idea 
of the MC6801.

> 
> 68HC11 adds Y but it's prefixed and slower so harder to use effectively.
> It's really important for stuff like asm memcpy() functions but in C I
> ended up using it as the upper half of the 32bit working value mostly as
> you can then ADDD n+2,X XGDY ADCB n+1,X ADCA n,X XGDY and so on.

Well, that looks somewaht similar to X and Y on STM8, which I am used to.

> HC08 is a totally different beastie and involves some fun managing
> whether your working 16bit value upper is in X or H according to what you
> are doing.

Yes. And we already have a port for that one.

Philipp

> Having had a quick look at the architecture, I think SDCC is a good 
> choice for a compiler targeting it. The instruction set, and adressing 
> modes look ok, the 16-bit stack pointer and index register will be quite 
> helpful. It is kind of a typical architecture for an SDCC target - not a 
> great target for C, but not too bad either.

It's an extremely nice machine for most C code generation as far as 8bit
processors go. It's probably better than pretty much anything except 6809
- certain beats the Z80 flat.

You do need to do good register tracking on the X register and also
know how to dynamically calculate offsets from the current X register
versus S at any point to make it work well. So for example you end up
doing stuff like

   TSX
   LDB #8
   ABX
   PSHX    ; push &x
   LDD 4,X ; tracking live X so we don't keep reloading with TSX

> The main difficulty will likely be the lack of an efficient 
> stackpointer-relative addressing mode, so stack accesses would have to 
> use the index register - and there is only one index register, which 
> also needs to be used for pointer accesses. Thus, you'll probably want 
> local variables to not be on the stack by default (like for mos6502, 
> pdk, mcs51, hc08).

Having written two 6801/3 compilers that isn't the case at all. You want
everything on the stack most of the time because indexed is faster and
more compact than extended.

See
https://github.com/EtchedPixels/Fuzix-Compiler-Kit

and the older
https://github.com/EtchedPixels/CC6303

which has then been built out for 6800 a lot more by Zu2

https://github.com/zu2/CC6303

As the Fuzix compiler actually runs on a 6801 you should be able to do a
lot better with SDCC as you've got room for a lot more higher level
optimisations but hopefully the fcc code will give you some ideas on how
to tackle it perhaps. It's also being used on the Tandy MC10, which is
about the only classic style 6803 home computer in existence.

> IMO, the MC6800 and MC6801 are so similar, that it would make sense to 
> create ports for both, which would then share register allocation and 

They are *totally* different beasts for a compiler. 6800 has no 16bit bit
operations of note and cannot stack and unstack the X register. That
dramatically changes how you need to do code generation if you want even
vaguely reasonable size. Some other stuff like stack adjustment ends up
really different too. Most 6800 compilers are bytecode engines but it is
possible to do C on a straight 6800 if you pull a few tricks (in
particular knowing that whilst you can't PULX you can TSX LDX ,X INS INS)

6801/3/6303 are fairly similar because the big difference for a compiler
is XGDX and that mostly translates to being able to do constant
adjustments of X better. 6801/3 is limited to ABX which destroys B on a
constant load whereas 6303 can do XGDX ADDD #nnnn XGDX. So XGDX totally
changes doing maths on X (and thus S) but it's a very localised change in
most compilers.

68HC11 adds Y but it's prefixed and slower so harder to use effectively.
It's really important for stuff like asm memcpy() functions but in C I
ended up using it as the upper half of the 32bit working value mostly as
you can then ADDD n+2,X XGDY ADCB n+1,X ADCA n,X XGDY and so on.

HC08 is a totally different beastie and involves some fun managing
whether your working 16bit value upper is in X or H according to what you
are doing.

6809 is very different in several ways. You have operations on ,S, you
have LEA both for things like address of stack objects and for doing
pointer maths on pointers in registers using U and Y without going via D.
The end result is a very very different code generator.

6309 is a whole further layer of fun with some 32bit ops and W etc.

> most of code generation (like e.g. the z80 port and the z180 port share 
> code generation). This would also mean that we need assemblers and 
> simulators for both. In principle, this could later even be extended to 
> M68HC11 and M68HC12 support, but is probably not be worth the effort, 
> since GCC already supports that one.

EmulatorKit has 6800/6801/6303/68HC11 emulation and is GPL, feel free to
borrow from it if useful. The Fuzix C compiler also uses that library for
its own self tests on 680x processors except 6809 (which is way different
as a target and uses a different emulator)

Alan

Am 08.12.25 um 09:43 schrieb Sebastien Lorquet:
> All the 68xx CPUs are variations on a similar base, so they could all be 
> supported with code generation options?

IMO, the 68HC08/68HCS08 are too different from MC6800/MC6801/HD6301 for 
that. We'll probably want to keep those two µC families separate wrt. 
SDCC support.


Philipp

well, there is already a lot of SDCC development happening now and 
planned for the near future. While it could happen later, I wouldn't 
want to make concrete plans for HC11 or 6809 ports in SDCC now. I'm 
worried that planning too big could prevent us from getting anything done.

I'd suggest the following next steps:

a) MC6800, MC6801, HD6301 sdas support
b) MC6801, HD6303 uCsim support
c) mc6800, mc6801, hd6301 SDCCports
d) HC11 and MC6809 sdas support

Since AFAIK upstream asxxxx already has MC6800, MC6801, HD6301, HC11, 
MC6809 support, it should be easy to port to sdas. Also AFAIK, uCsim 
already has MC6800, HC11 and MC6809 support (not sure about MC6801 and 
HC6303), but it is not yet in the SDCC repo.

Full HC11/MC6809 support could then be considered again, once we have 
the above in place.

Philipp

P.S.: I'll be quite busy with other stuff for the next few months. I 
should still be able to help with c), in particular code generation and 
register allocation, but won't be able to help with a), b), or d).

Hello

The 68hc11 support by GCC is not very good and is limited to an old 
release, so there is no more support for it, and last time I tried, I 
found it quite heavy and rigid in structure. It requires additional RAM 
mapped pseudo-registers, which facilitate gcc code generation but these 
are a burden in many embedded cases. GDB and binutils still have full 
support.

This CPU is quite annoying because of its lack of stack or pc relative 
modes. It has the TSX and TXS opcodes to access SP, but this is 
inefficient. Memory mapped local variables would be better, keeping the 
stack for the rare reentrant code that need it. Using Y as SP is another 
possibility, but the generated code looses quite a bit of compacity 
because the Y-based opcodes need a prefix.

The culmination of this effort could be support for the 6809, because 
even if that one is theoretically supported by several gcc based 
toolchains, support is clumsy and documentation/chains are very 
scattered across the internet. you find patches for several gcc 
versions, but no single good "source tree" to download and build easily. 
A 6809 SDCC would likely be much better in general quality, code 
quality, and compacity.

(I have written simulators for the 68hc11 and 6809).

All the 68xx CPUs are variations on a similar base, so they could all be 
supported with code generation options?

It's difficult for me to be a project leader of any kind but I can help 
with some testing.

I should be getting a Epson HX-20 in 2026, so it would be fun to use 
sdcc to write code on it :)

Sebastien


On 12/7/25 2:26 PM, Philipp Klaus Krause wrote:
> Am 07.12.25 um 13:12 schrieb tcfkat--- via Sdcc-user:
>> I would very much welcome support for MC680x. The Hitachi HD6303 
>> clone has an extended instruction set, so perhaps that could be 
>> supported as well. Original Motorola has 59 illegal or better unused 
>> opcodes, while Hitachi has only 26. (I started a long time ago 
>> writing a MC6800 simulator, but never finished.)
>
> I agree, though I don't think the HD6301/HD6303 additions over the 
> MC6801 (10 additional opcodes, or so I think) matter that much, AFAIK 
> they are mostly just about bitwise operations on memory operands. But 
> combined with the timing differences an extra port would be worth it.
>
> As far as I can see, we have instruction sets:
>
> MC6800 ⊊ MC6801 ⊊ HD6301.
>
> That could be three ports (possibly named mc6800 mc6801 hd6301 or 
> similar), that  would then share most of the code.
>
> I don't know how much time I'd find to contribute, but I think I could 
> do some or most of the work on code generation and register allocation.
>
> But first, we need assembler and simulator support for at least one of 
> the three architecture variants each.
>
> Philipp
>
>
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Am 07.12.25 um 13:12 schrieb tcfkat--- via Sdcc-user:
> I would very much welcome support for MC680x. The Hitachi HD6303 clone 
> has an extended instruction set, so perhaps that could be supported as 
> well. Original Motorola has 59 illegal or better unused opcodes, while 
> Hitachi has only 26. (I started a long time ago writing a MC6800 
> simulator, but never finished.)

I agree, though I don't think the HD6301/HD6303 additions over the 
MC6801 (10 additional opcodes, or so I think) matter that much, AFAIK 
they are mostly just about bitwise operations on memory operands. But 
combined with the timing differences an extra port would be worth it.

As far as I can see, we have instruction sets:

MC6800 ⊊ MC6801 ⊊ HD6301.

That could be three ports (possibly named mc6800 mc6801 hd6301 or 
similar), that  would then share most of the code.

I don't know how much time I'd find to contribute, but I think I could 
do some or most of the work on code generation and register allocation.

But first, we need assembler and simulator support for at least one of 
the three architecture variants each.

Philipp

I would very much welcome support for MC680x. The Hitachi HD6303 clone has an extended instruction set, so perhaps that could be supported as well. Original Motorola has 59 illegal or better unused opcodes, while Hitachi has only 26. (I started a long time ago writing a MC6800 simulator, but never finished.)

Eric
    Am Sonntag, 7. Dezember 2025 um 12:42:02 MEZ hat Philipp Klaus Krause <pk...@sp...> Folgendes geschrieben:  
 
 Am 06.12.25 um 22:31 schrieb Hill, Krista:
> I see that I have some digging to do. I'm using 
> the as6801 assembler and aslink linker from the ASxxxx tools and so far, 
> so good.
> 
> So far I  see that uCsim will need some work to support the 6801 cpu and 
> devices. It's one step at a time.

Having had a quick look at the architecture, I think SDCC is a good 
choice for a compiler targeting it. The instruction set, and adressing 
modes look ok, the 16-bit stack pointer and index register will be quite 
helpful. It is kind of a typical architecture for an SDCC target - not a 
great target for C, but not too bad either.

The main difficulty will likely be the lack of an efficient 
stackpointer-relative addressing mode, so stack accesses would have to 
use the index register - and there is only one index register, which 
also needs to be used for pointer accesses. Thus, you'll probably want 
local variables to not be on the stack by default (like for mos6502, 
pdk, mcs51, hc08).

IMO, the MC6800 and MC6801 are so similar, that it would make sense to 
create ports for both, which would then share register allocation and 
most of code generation (like e.g. the z80 port and the z180 port share 
code generation). This would also mean that we need assemblers and 
simulators for both. In principle, this could later even be extended to 
M68HC11 and M68HC12 support, but is probably not be worth the effort, 
since GCC already supports that one.

Philipp



_______________________________________________
Sdcc-user mailing list
Sdc...@li...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
  

Am 06.12.25 um 22:31 schrieb Hill, Krista:
> I see that I have some digging to do. I'm using 
> the as6801 assembler and aslink linker from the ASxxxx tools and so far, 
> so good.
> 
> So far I  see that uCsim will need some work to support the 6801 cpu and 
> devices. It's one step at a time.

Having had a quick look at the architecture, I think SDCC is a good 
choice for a compiler targeting it. The instruction set, and adressing 
modes look ok, the 16-bit stack pointer and index register will be quite 
helpful. It is kind of a typical architecture for an SDCC target - not a 
great target for C, but not too bad either.

The main difficulty will likely be the lack of an efficient 
stackpointer-relative addressing mode, so stack accesses would have to 
use the index register - and there is only one index register, which 
also needs to be used for pointer accesses. Thus, you'll probably want 
local variables to not be on the stack by default (like for mos6502, 
pdk, mcs51, hc08).

IMO, the MC6800 and MC6801 are so similar, that it would make sense to 
create ports for both, which would then share register allocation and 
most of code generation (like e.g. the z80 port and the z180 port share 
code generation). This would also mean that we need assemblers and 
simulators for both. In principle, this could later even be extended to 
M68HC11 and M68HC12 support, but is probably not be worth the effort, 
since GCC already supports that one.

Philipp

Thanks for your reply. I see that I have some digging to do. I'm using the as6801 assembler and aslink linker from the ASxxxx tools and so far, so good.

So far I  see that uCsim will need some work to support the 6801 cpu and devices. It's one step at a time.

Krista


________________________________
From: Philipp Klaus Krause <pk...@sp...>
Sent: Saturday, December 6, 2025 3:51 PM
To: sdc...@li... <sdc...@li...>
Subject: [External-email]: Re: [Sdcc-user] SDCC support for MC6801 processor?

**Caution: This email was sent from outside the university. Please exercise caution when clicking links, opening attachments, or replying. When in doubt, contact the helpdesk.**


Am 06.12.25 um 18:06 schrieb Hill, Krista:
> Hello folks,
>
> I'm looking about for support for the 6801 micro, which has some useful
> features over the MC6800. In particular the A and B accumulators to form
> the 16 bit D register. I see that there is support for the 68HC08 and
> S08 which are related.
>
> Please, I'd like to know if there is or ever was any  interest in the
> 6801 micro. Also, a vague outline of what it would take to get the SDCC
> to provide such support, would be appreciated.
>
> Thanks in advance,
> Krista

See https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fsdcc%2Fwiki%2FAdding%2520a%2520port%2F&data=05%7C02%7Ckmhill%40hartford.edu%7Cee476b3402ea4bb0f12b08de35096c9e%7Cb78b91e8428e422fa5b4a8f6cab07104%7C0%7C0%7C639006511754501929%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jleny65qk7dz45QpFTdzARdgyGskkrA4HtNH1bGJhzE%3D&reserved=0<https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/>; assembler
and simulator support is usually the first step. In the case of the
6801, upstream asxxxx has 6801 support, which could be ported to sdas
for the assembler.

Philipp



_______________________________________________
Sdcc-user mailing list
Sdc...@li...
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fsdcc-user&data=05%7C02%7Ckmhill%40hartford.edu%7Cee476b3402ea4bb0f12b08de35096c9e%7Cb78b91e8428e422fa5b4a8f6cab07104%7C0%7C0%7C639006511754534814%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jG%2FDbY9I8h%2FvS0TWnrCYwEOi%2F5VegzfI%2F7T7jsJQ%2BnY%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/sdcc-user>

Am 06.12.25 um 18:06 schrieb Hill, Krista:
> Hello folks,
> 
> I'm looking about for support for the 6801 micro, which has some useful 
> features over the MC6800. In particular the A and B accumulators to form 
> the 16 bit D register. I see that there is support for the 68HC08 and 
> S08 which are related.
> 
> Please, I'd like to know if there is or ever was any  interest in the 
> 6801 micro. Also, a vague outline of what it would take to get the SDCC 
> to provide such support, would be appreciated.
> 
> Thanks in advance,
> Krista

See https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/; assembler 
and simulator support is usually the first step. In the case of the 
6801, upstream asxxxx has 6801 support, which could be ported to sdas 
for the assembler.

Philipp

Hello folks,

I'm looking about for support for the 6801 micro, which has some useful features over the MC6800. In particular the A and B accumulators to form the 16 bit D register. I see that there is support for the 68HC08 and S08 which are related.

Please, I'd like to know if there is or ever was any  interest in the 6801 micro. Also, a vague outline of what it would take to get the SDCC to provide such support, would be appreciated.

Thanks in advance,
Krista

On 12/2/25 13:22, erl...@gm... wrote:
> I get your point. Maybe some MISRA on/off og something like that could
> feasible. Whenever I do C, i check all warnings (and of course errors)
> based on the assumption that there should be no woarnings. MOst of them
> refer to some code construct that may need scrutinizing. Just my 2 cent

And even more, for some constructs that emit those warnings, most of
the time, they should be rewritten in a warning free manner.
For the very few occurence that it is by design, there should be
#pragma that can disable some warnings for a small code area.
That way we have the best of every side on the coin.

On Tue, Dec 2, 2025 at 7:56 PM Dave McGuire <mc...@ne...> wrote:
> I agree, and everything I write is compiled with -Wall too, but I
> think most people don't work that way.

And that's one of the reasons that rust feels much safer than C.
It's not only the language.
It's mostly that people are accepting warnings from the rust compiler
that they fight against in C.

Cheers
--
Steve Schnepp

On 12/2/25 13:22, erl...@gm... wrote:
>> > Anything the compiler can detect at compiletime should be either a > 
>> warning or an error.
>> > Coming from Ada, it seems weird that the compiler does not flag > 
>> everything it can detect at compile time. It saves so much debugging.
>>    The danger here is when the compiler flags things which aren't 
>> actually problems, which happens all the time in C.  Then warnings 
>> become annoying, then get turned off or ignored, which can cause real 
>> problems to get missed at compile time.
>>
>>    So, there is a balance to be struck here.
>
> I get your point. Maybe some MISRA on/off og something like that could 
> feasible. Whenever I do C, i check all warnings (and of course errors) 
> based on the assumption that there should be no woarnings. MOst of them 
> refer to some code construct that may need scrutinizing. Just my 2 cent

   I agree, and everything I write is compiled with -Wall too, but I 
think most people don't work that way.

              -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA

On 01.12.2025 20.30, Dave McGuire <mc...@ne...> wrote:
> On 12/1/25 14:25, erl...@gm... wrote:
> > Anything the compiler can detect at compiletime should be either a 
> > warning or an error.
> > Coming from Ada, it seems weird that the compiler does not flag 
> > everything it can detect at compile time. It saves so much debugging.
>    The danger here is when the compiler flags things which aren't 
> actually problems, which happens all the time in C.  Then warnings 
> become annoying, then get turned off or ignored, which can cause real 
> problems to get missed at compile time.
> 
>    So, there is a balance to be struck here.
> 
>              -Dave
> 
> 
I get your point. Maybe some MISRA on/off og something like that could feasible. Whenever I do C, i check all warnings (and of course errors) based on the assumption that there should be no woarnings. MOst of them refer to some code construct that may need scrutinizing. 
Just my 2 cent
Erlo

On 12/1/25 14:25, erl...@gm... wrote:
> Anything the compiler can detect at compiletime should be either a 
> warning or an error.
> Coming from Ada, it seems weird that the compiler does not flag 
> everything it can detect at compile time. It saves so much debugging.
   The danger here is when the compiler flags things which aren't 
actually problems, which happens all the time in C.  Then warnings 
become annoying, then get turned off or ignored, which can cause real 
problems to get missed at compile time.

   So, there is a balance to be struck here.

             -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA

On 26.11.2025 17.23, Philipp Klaus Krause <pk...@sp...> wrote:
> Formally, array parameters (without static) are no different from 
> pointer parameters. However, they have often been used to express the 
> intent of the parameter being an array of a certain size.
> 
> Do you have any preferences on what SDCC should do? Currently SDCC does 
> not warn (neither does clang), while GCC sometimes does:
> 
> 
> // Tested via gcc/clang -Wall -pedantic -Warray-parameter -Warray-bounds 
> test.c
> 
> void f(char a[4])
> {
>      a[4] = 7; // neither gcc nor clang warn
> }
> 
> void g(void)
> {
>      char a[3];
>      f(a); // gcc warns, clang doesn't.
>      f(0); // neither gcc nor clang warn
> }
> 
> 
> Would you like to see warnings in SDCC for any of these?
> 
> Philipp
> 
> 
> 
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 
Anything the compiler can detect at compiletime should be either a warning or an error.
Coming from Ada, it seems weird that the compiler does not flag everything it can detect at compile time. It saves so much debugging.

Erlo

Philipp Klaus Krause schreef op 2025-11-24 14:22:
> Am 24.11.25 um 13:54 schrieb Maarten Brock:
>> 
>> I would not qualify the stack as large for the mcs51 large & huge
>> memory models. Medium, large and huge do not place every variable in
>> the <= 248 bytes data memory, but still use it for itemps. So stack
>> space (= unallocated idata) remains very limited.
>> 
>> And when using --xstack the stack still is limited to 256 bytes pdata.
>> There is no stack implementation in xdata.
>> 
> […]
>> 
>> So my recommendation is to keep this behaviour for all targets with a
>> stack space of 256 bytes or less.
> 
> Except pdk, where despite the the stack being small, there is no point
> in omitting the promotion (and AFAIR pdk never omitted it). I'm not
> sufficiently familiar with ds390 to make changes there, so I guess for
> now, we'd keep the omission for ms51, mos6502, mos65c02, ds390.

For ds390 it would probably be OK to do the promotion as the stack space
is 1024 bytes there, IIRC.

Maarten

Philipp Klaus Krause schreef op 2025-11-26 17:23:
> Formally, array parameters (without static) are no different from
> pointer parameters. However, they have often been used to express the
> intent of the parameter being an array of a certain size.
> 
> Do you have any preferences on what SDCC should do? Currently SDCC
> does not warn (neither does clang), while GCC sometimes does:
> 
> 
> // Tested via gcc/clang -Wall -pedantic -Warray-parameter 
> -Warray-bounds test.c
> 
> void f(char a[4])
> {
> 	a[4] = 7; // neither gcc nor clang warn
> }
> 
> void g(void)
> {
> 	char a[3];
> 	f(a); // gcc warns, clang doesn't.
> 	f(0); // neither gcc nor clang warn
> }
> 
> 
> Would you like to see warnings in SDCC for any of these?
> 
> Philipp

I would like to see warnings for both cases.

Maarten

Agree, IMHO warning, in this case, is useful.

On Wed, Nov 26, 2025 at 5:51 PM Steve Schnepp <ste...@gm...> wrote:
>
> For me, more warnings is always better, as the lack if those is what makes C so much error prone.
>
> Any compile time check is worth a thousand runtime checks as it is mostly free.
>
> Cheers,
> --
> Steve Schnepp
>
> "A man is not dead while his name is still spoken."
>     -- T. Pratchett - Going Postal, Chapter 4 prologue
>
> On Wed, Nov 26, 2025, 17:24 Philipp Klaus Krause <pk...@sp...> wrote:
>>
>> Formally, array parameters (without static) are no different from
>> pointer parameters. However, they have often been used to express the
>> intent of the parameter being an array of a certain size.
>>
>> Do you have any preferences on what SDCC should do? Currently SDCC does
>> not warn (neither does clang), while GCC sometimes does:
>>
>>
>> // Tested via gcc/clang -Wall -pedantic -Warray-parameter -Warray-bounds
>> test.c
>>
>> void f(char a[4])
>> {
>>         a[4] = 7; // neither gcc nor clang warn
>> }
>>
>> void g(void)
>> {
>>         char a[3];
>>         f(a); // gcc warns, clang doesn't.
>>         f(0); // neither gcc nor clang warn
>> }
>>
>>
>> Would you like to see warnings in SDCC for any of these?
>>
>> Philipp
>>
>>
>>
>> _______________________________________________
>> Sdcc-user mailing list
>> Sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user



-- 
BR/Pozdrawiam. Wlodzimierz Lipert