Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2860 > unrolled thread

GCC for 6502

Back to article view | Back to comp.sys.apple2.programmer

Contents

  GCC for 6502 D Finnigan <dog_cow@macgui.com> - 2016-08-01 22:45 +0000
    Re: GCC for 6502 mmphosis <mmphosis@macgui.com> - 2016-08-02 16:11 +0000
      Re: GCC for 6502 D Finnigan <dog_cow@macgui.com> - 2016-08-02 19:09 +0000
    Re: GCC for 6502 Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-03 10:35 -0700
    Re: GCC for 6502 David Schmenk <dschmenk@gmail.com> - 2016-08-03 13:30 -0700
      Re: GCC for 6502 D Finnigan <dog_cow@macgui.com> - 2016-08-03 21:24 +0000
        Re: GCC for 6502 Bill Buckels <bbuckels@escape.ca> - 2016-08-03 17:57 -0700
          Re: GCC for 6502 D Finnigan <dog_cow@macgui.com> - 2016-08-04 17:40 +0000
            Re: GCC for 6502 handyandy802@gmail.com - 2017-07-06 12:05 -0700
    Re: GCC for 6502 D Finnigan <dog_cow@macgui.com> - 2016-08-08 19:11 +0000

#2860 — GCC for 6502

I found a discussion on 6502.org relative to a version of the GCC for 6502
systems.

It's Build tools, tiny C library, etc. for gcc-6502 port.

Prerequisites

You need to install cc65 in /usr (so ca65, ld65 and so on are present in
/usr/bin/ca65 etc.) before building. On a Debian system you should also have
all the prerequisites for building GCC installed.

Work in progress

This is a work-in-progress compiler, and many bugs remain. You can build
code for semi65x (the included simulator), and limited support also exists
for Acorn BBC Model B or Master computers (you may see some references to
the C64, but that's not properly implemented yet). Adding support for other
systems shouldn't be too hard - contact me if you'd like to try that!

Last activity was about 3 weeks ago.

Links:
https://github.com/puppeh/gcc-6502
https://github.com/puppeh/gcc-6502-bits

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [next] | [standalone]

#2861

Thanks for the reminder about this.  Those links showed up on Hacker News
about 3 weeks ago:

https://news.ycombinator.com/item?id=12082503

[toc] | [prev] | [next] | [standalone]

#2862

mmphosis wrote:
> Thanks for the reminder about this.  Those links showed up on Hacker News
> about 3 weeks ago:
> 
> https://news.ycombinator.com/item?id=12082503
>

I site I don't read often enough, it seems! :-P

Tracing the parentage of those comments I arrived at this one:

https://news.ycombinator.com/item?id=12080871

--------------------

white-flame 20 days ago [-]

Static optimization to inlined code that ONLY handles immediate numbers and
addresses is fine, and interesting to see the full pipeline working. But
that possibility is there really for any language and any asm platform. I
remember seeing Forth compile down to 6502 or other asm code, where it
compiled down to the asm instructions a human would write for the same task,
with basically zero language overhead.
HOWEVER, that was because the code written only did things similar to
assembly instructions, similar to this example.

The biggest problem with compiling C family languages to 6502 is the stack.
They generally assume something like a local stack frame for variables and
parameters, and there's no way to directly express that style of programming
at the 6502 instruction level. Note that there were no local variables in
these examples, much less any actual function calls. Certainly the ABI used
by C would not be machine-code-translatable from x86 to 6502; there would be
an ABI written for 6502 and higher level targeting could work.

Instead of generating & trying to translate x86 assembly code, compiling
C++14 down to plain C and using a 6502 compiler like cc65 could work
significantly better for more idiomatic C++.

While it's an interesting novelty, why write 50+ lines of C++ code when
writing 7 lines of commented, well-understood assembly instructions suffice?
Add some variables and macros to take care of naming the various bits &
locations, or target some codegen directly to 6502 if we're talking about
programming "in the large" relatively speaking. Sure, you don't want to
touch x64 code for human writing in the general case, but 6502 was designed
with hand coding in mind.


------------------------
	
to3m 20 days ago [-]

Yes. This doesn't strike me as an especially productive line of attack, but
maybe I'm missing something (hopefully not obvious), maybe I'm just not
imaginative enough, and/or maybe I'm underestimating how much effort people
might be willing to put into such an endeavour.
This did get me thinking about the problem a bit this evening though. The
6502 is an awful target for many higher-level languages, but I think you
could compile something like C, if you treat zero page as the stack for
locals, and index it by X. The programmer would need to be aware of the
target's rather tiresome limitations, but you'd get somewhat passable code
at least.

(Unlike absolute addressing, you do pay a 1-cycle penalty for indexed zero
page accesses, but what can you do? You need to store things in zero page to
handle pointers.)

Suppose you had a function with a couple of locals, like this:

    void strip(char *p,char c) {
        unsigned char *dest=p;
        do {
            if(*p!=c) *dest++=*p;
        } while(*p++!=0);
    }

So you'd store c (1 byte), then p (2 bytes), and then once the space for
locals is reserved, zero page starting from the address in X would look like
this:

    +0, +1 = dest
    +2, +3 = p
    +4     = c

So the ideal generated code would go along these lines:

	DEX:DEX					; reserve space for locals
	LDA 2,X:STA 0,X:LDA 3,X:STA 1,X	; dest=p
	.L0
	LDA (2,X)					; *p
	CMP 4,X
	BEQ L1					; taken when *p==c
	STA (0,X)					; *dest=*p
	INC 0,X:BNE L2:INC 1,X:.L2		; ++dest
	.L1
	LDA (2,X)					; *p
	INC 2,X:BNE L3:INC 3,X:.L3		; ++p
	CMP #0
	BNE L0					; taken when *p!=0
	INX:INX
	RTS

I don't think many people would write code like that by hand, but it's not
completely insane given the requirements.
This has actually now piqued my interest enough to make me think about
actually coding something, so I guess that answers the question about how
much effort somebody might be willing to put into such an endeavor.

Other thoughts:

- since ZP,X costs like ABS,Y, maybe have a second stack in main memory for
non-pointers and index it with the Y register (the RMW instructions don't
have an appropriate addressing mode though)

- you could statically allocate zero page for many programs, which would
make it easier to use the (ZP),Y addressing mode

- turning canned snippets (like the INC/BNE/INC) into routines would
probably be rarely beneficial, since getting the address into X is rather
involved

- I've never used a C compiler for the 6502 so maybe they all do this anyway
;)


---------------------------



vitd 20 days ago [-]

Oh man, I remember trying to understand AppleDOS and 6502 Assembly on the
Apple II+ when I was a wee lad. It was so confusing what all these hex
memory locations were. Being able to give them actual function names (or
even just named constants!) would have made things so much easier!

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [prev] | [next] | [standalone]

#2869

On Monday, August 1, 2016 at 3:45:33 PM UTC-7, D Finnigan wrote:
> I found a discussion on 6502.org relative to a version of the GCC for 6502
> systems.

While I understand the desire to run GCC on everything under the sun, including your toaster, and as much as I love C, and tolerate C++ as a "Better C then C", I question this philosophy.  "Just because you can doesn't mean you should."

Aside from the intellectual curiosity, using C on the 6502 is dumb IMO as it generates bloated 6502 assembly code + data.

For example, printf() wastes memory for:

a) data -- i.e. the meta-character '%', width character, etc. 
b) code -- Worse, you can't turn features on/off.  

Seriously, when was the _last_ time you _needed_ octal printing on the Apple 2 ???  Gee, how about something more useful like _binary_ output or even "inverse" binary output !!

My printm() replacement ...
https://github.com/Michaelangel007/apple2_printm

... solves all these problems of C's brain-dead printf:

a) modular
b) hand-tuned for size, both code and data,
c) It has a wide variety of output options:

    $ Hex - print 1 Byte  (2 characters)
    x Hex - print 2 Bytes (4 characters)

    @ Ptr - print hex 1 Byte  at 16-bit pointer
    & Ptr - print hex 2 Bytes at 16-bit pointer

    # Dec - Print 1 Byte  in decimal (max 2 digits)
    d Dec - Print 1 Byte  in decimal (max 3 digits)
    u Dec - Print 2 Bytes in decimal (max 5 digits)
    b Dec - Print signed 1 Byte in decimal

    % Bin - Print 8 bits
    ? Bin - Print 8 bits but 1's in inverse

    o Oct - Print 1 Byte in octal (max 3 digits)
    O Oct - Print 2 Byte in octal (max 6 digits)

    a Str - APPLE text (high bit set), last char is ASCII
    s Str - C string, zero terminated
    p Str - Pascal string, first byte is string length


While C/C++ is excellent for fast prototyping / programming on x86, I find it to be of dubious value for the 6502.  There is nothing I can do in C that I couldn't already do with 6502 hand-rolled assembly.

I guess if you're programming for the 6502 and still don't know assembly (it's never too late to learn!) I could see it being of practical value.


Still, an interesting idea.  I just question it's value (for me) and the sanity of others. :-)

[toc] | [prev] | [next] | [standalone]

#2871

On Monday, 1 August 2016 15:45:33 UTC-7, D Finnigan  wrote:
> I found a discussion on 6502.org relative to a version of the GCC for 6502
> systems.
> 
> It's Build tools, tiny C library, etc. for gcc-6502 port.
> 
> Prerequisites
> 
> You need to install cc65 in /usr (so ca65, ld65 and so on are present in
> /usr/bin/ca65 etc.) before building. On a Debian system you should also have
> all the prerequisites for building GCC installed.
> 
> Work in progress
> 
> This is a work-in-progress compiler, and many bugs remain. You can build
> code for semi65x (the included simulator), and limited support also exists
> for Acorn BBC Model B or Master computers (you may see some references to
> the C64, but that's not properly implemented yet). Adding support for other
> systems shouldn't be too hard - contact me if you'd like to try that!
> 
> Last activity was about 3 weeks ago.
> 
> Links:
> https://github.com/puppeh/gcc-6502
> https://github.com/puppeh/gcc-6502-bits
> 
> -- 
> ]DF$
> The Marina IP stack for Apple II--
> http://marina.a2hq.com/

I looked into porting GCC and LLVM to the 6502 some time ago. Basically, those C compilers want a destination with registers. What doesn't the 6502 have? Registers. So you end up doing exactly what is discussed in the posts: creating a pseudo-machine that is a sane target for the compiler and still has a chance of running somewhat efficiently on the 6502. I think overall, cc65 does about a good of a job as you can expect for a 6502 targeted C compiler. C is my language of choice on everything except the 6502. Then I go PLASMA (shameless plug) and assembly. It's not as if you are going to port many Unix utilities to the Apple II, anyway.

Dave...

[toc] | [prev] | [next] | [standalone]

#2872

David Schmenk wrote:
> 
> I looked into porting GCC and LLVM to the 6502 some time ago. Basically,
> those C compilers want a destination with registers. What doesn't the 6502
> have? Registers. So you end up doing exactly what is discussed in the
> posts: creating a pseudo-machine that is a sane target for the compiler
> and
> still has a chance of running somewhat efficiently on the 6502.

Discussion of C compilers on the Apple II is as old as dirt. And we may get
a chance to see another implementation before the second coming of Christ.
We need to tap Sheldon Simms on the shoulder and ask him how he's doing with
his Unix v6 port. :-)

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [prev] | [next] | [standalone]

#2873

On Wednesday, 3 August 2016 16:24:32 UTC-5, D Finnigan  wrote:
> David Schmenk wrote:
> > 
> > I looked into porting GCC and LLVM to the 6502 some time ago. Basically,
> > those C compilers want a destination with registers. What doesn't the 6502
> > have? Registers. So you end up doing exactly what is discussed in the
> > posts: creating a pseudo-machine that is a sane target for the compiler
> > and
> > still has a chance of running somewhat efficiently on the 6502.
> 
> Discussion of C compilers on the Apple II is as old as dirt. And we may get
> a chance to see another implementation before the second coming of Christ.
> We need to tap Sheldon Simms on the shoulder and ask him how he's doing with
> his Unix v6 port. :-)
> 
> -- 
> ]DF$
> The Marina IP stack for Apple II--
> http://marina.a2hq.com/

Discussion of C compilers on the Apple II may be old as dirt, but Aztec C65 and cc65 are more than discussion as cross-compilers go... I for one am happy with them... could always use some more though.
 

[toc] | [prev] | [next] | [standalone]

#2875

Bill Buckels wrote:
> 
> Discussion of C compilers on the Apple II may be old as dirt, but Aztec
> C65
> and cc65 are more than discussion as cross-compilers go... I for one am
> happy with them... could always use some more though.
>

True. Aztec C. Now there's an interesting product. I wonder if it came too
late to the Apple II platform, or if it didn't penetrate the developer's
market enough to build a sturdy user base. We should have a lot more
user-contributed sample programs and libraries, I think, if it really had a
strong installed base.

I fiddled around last evening with the Aztec C Plus compilation, trying to
compile the p.c program that's given on page xxx in the Kernighan book on
Unix Programming Environment. No dice. Looks like the shell isn't loading
the profile file to set the correct environment paths.

Anyway that got me searching through this Usenet archive that I have and I
found this interesting little essay from early 1989:
http://macgui.com/usenet/?group=7&id=9791#msg

It's a proposal for a 16-bit C compiler for 8-bit Apples. So you'd need to
get the 65802 to run it.

Brian writes 
"My other compiler is Aztec C. It produces too much object code and text 
output is terribly slow. The reason stems from the 6502's lack of a large 
stack. 256 bytes is not enough for a high level recursive language, so the 
Aztec compiler inserts code to copy the stack to a software stack of
sufficient 
size. This, coupled with the 8-bit nature of the 6502, requires a lot of 
instructions to get anything useful done. 

"Since I have been looking for a more efficient C compiler, but can't seem 
to find one, I started brainstorming. With the source for Small C, and an 
assembler which works with a 16-bit 65C802, it should be possible to rewrite

the Assembler Macros that the compiler uses (this source is also included)
to 
use the 65C802 instructions. Thus the processor could access a true 64K
stack, 
not a software simulated stack. There would be many other benefits such as 
faster manipulation of 16-bit data and smaller code. "


Brian predicted its fate too: "Unfortunately, no product like this will come
out since not many Apple II owners have the 65C802 plugged into their
board."

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [prev] | [next] | [standalone]

#3635

On Thursday, August 4, 2016 at 1:40:21 PM UTC-4, D Finnigan wrote:
> Bill Buckels wrote:
> > 
> > Discussion of C compilers on the Apple II may be old as dirt, but Aztec
> > C65
> > and cc65 are more than discussion as cross-compilers go... I for one am
> > happy with them... could always use some more though.
> >
> 
> True. Aztec C. Now there's an interesting product. I wonder if it came too
> late to the Apple II platform, or if it didn't penetrate the developer's
> market enough to build a sturdy user base. We should have a lot more
> user-contributed sample programs and libraries, I think, if it really had a
> strong installed base.
> 
> I fiddled around last evening with the Aztec C Plus compilation, trying to
> compile the p.c program that's given on page xxx in the Kernighan book on
> Unix Programming Environment. No dice. Looks like the shell isn't loading
> the profile file to set the correct environment paths.
> 
> Anyway that got me searching through this Usenet archive that I have and I
> found this interesting little essay from early 1989:
> http://macgui.com/usenet/?group=7&id=9791#msg
> 
> It's a proposal for a 16-bit C compiler for 8-bit Apples. So you'd need to
> get the 65802 to run it.
> 
> Brian writes 
> "My other compiler is Aztec C. It produces too much object code and text 
> output is terribly slow. The reason stems from the 6502's lack of a large 
> stack. 256 bytes is not enough for a high level recursive language, so the 
> Aztec compiler inserts code to copy the stack to a software stack of
> sufficient 
> size. This, coupled with the 8-bit nature of the 6502, requires a lot of 
> instructions to get anything useful done. 
> 
> "Since I have been looking for a more efficient C compiler, but can't seem 
> to find one, I started brainstorming. With the source for Small C, and an 
> assembler which works with a 16-bit 65C802, it should be possible to rewrite
> 
> the Assembler Macros that the compiler uses (this source is also included)
> to 
> use the 65C802 instructions. Thus the processor could access a true 64K
> stack, 
> not a software simulated stack. There would be many other benefits such as 
> faster manipulation of 16-bit data and smaller code. "
> 
> 
> Brian predicted its fate too: "Unfortunately, no product like this will come
> out since not many Apple II owners have the 65C802 plugged into their
> board."
> 
> -- 
> ]DF$
> The Marina IP stack for Apple II--
> http://marina.a2hq.com/

I actually did just that for a Laser 128EX w/65802 installed.  It seemed to me that HyperC's pseudo-code interpreter was begging to be written in native mode as the pseudo-code interpreter emulated a 16 bit machine and a 65802 was one in native mode (and besides, there was nothing out there that I could find that was written for the 65802 and was discouraged by apple inc.).  There was perhaps a 20% speed up in execution due to my code (being a self-taught programmer) and switching back and forth from emulation mode to native mode so rom code and prodos would work.  Last I checked the executable I uploaded many moons ago is still available for download.

Cheers!
Andy

[toc] | [prev] | [next] | [standalone]

#2891

Here is another one for consideration:
http://oric.free.fr/COMPILERS/gcc6502.src.tgz

These are the files necessary to configure GCC to generate code for a 6502
microprocessor.

===============================================================================

		Targeting GCC for a 6502 Microprocessor

			2/3/97

		By Dave_Mcwherter@franklin.com

===============================================================================
Introduction

This document describes a port of GCC to the 6502 microprocessor. (This port
is
referred to as GCC02 in the rest of this document). The port was done at
Franklin
Electronic Publishers, Inc. to support development of their electronic books
on their BOOKMAN (registered trademark of Franklin Electronic Publishers,
Inc.)
platforms. It generates assembly code for the in-house Franklin 6502
assembler
Asm6, which is not part of this contribution. Changing the assembly output
to
accomodate other assemblers should not be difficult, however.

The port was originally done using GCC version 2.6.3 and has since been
tested
with GCC version 2.7.2. The port was done on a Macintosh Power PC using the
Metrowerks Codewarrior C compiler versions CW8 through CW10. Getting GCC
to build and run on a non-Unix box is a worthwhile topic in its own right.

*** There are changes necessary to the GCC source files to support this
port!!!!
*** Not everything could be accomplished using the 'standard' GCC porting
*** mechanisms. These changes are described at the end of this document.

===============================================================================
Deviations from ANSI C

* All local storage is static - local variables which overflow the sixteen
	zero-page registers will be allocated from static RAM.

* Functions which have more than twelve arguments will cause the compiler to
	abort. (Because a frame pointer is not supported.)

* GCC02 does not promote chars to ints in these three situations:
	- case selections in switch statements
	- function arguments
	- function return values
	(These are done via changes to the GCC source code, so you don't
	have to make the changes if you don't want to.)

* The standard GCC option '-fshort-enums' is hard-wired ON to make
enumerated
things only as big as they need to be (most often, they will be of size
char).

* 'size_t' is defined as 16 bits.

* Nested functions are not supported yet.

* Floating point or long longs are not supported yet.

All of these changes were done so that we could generate code for a typical
Franklin application as efficiently as possible without any overhead which
our applications would never use anyway.

===============================================================================
Compiling

You must use the -b6502 switch to select 6502 code generation.

GCC02 can only generate 6502 code at optimization level 2, so that's
hard-wired into the compiler (because a frame pointer is not supported). You
can select any other optimization level you want and it will have no effect.

Other options: (described in detail somewhere below)

	-mconfig-filename	specify filename as the configuration file

	-m16bitx		don't convert 16-bit indices to 8-bit

	-mdoasr			don't convert asr's to lsr's

	-mfarcall		support Franklin's farcall system (not
				supported in this submission)

===============================================================================
Output format

GCC02 produces assembly code in Asm6 (Franklin's in-house assembler) format.
Asm6 is not part of this submission and is not available from Franklin.

===============================================================================
Target model

GCC02 is implemented using a pseudo-register model because the 6502 doesn't
have anywhere near enough registers to properly support a machine of the
class
which GCC expects. There are 16 24-bit pseudo-registers r0-r15 located in
zero
page. There is also a 24-bit temporary register "t" in zero page. All other
RAM
is available for the compiled application.

GCC02 also uses the 6502 A, X, and Y registers as a 24-bit temporary
register.



===============================================================================
Coding tips

These are things you can do in your C source code to make your generated
6502 code better...

Avoid signed variables. Sign extension is expensive on the 6502. If a
variable
requires signedness only occasionally and can be unsigned most of the time,
consider casting it when you need the signedness. If it always must be
signed,
then consider casting it to unsigned especially if you use it as an index
into
an array, unless you absolutely need to go backwards from the base of the
array.

Make sure your BOOL's and BOOLEAN's are typedef'ed as 8 bits.

Remember that long's are 24 bits - not 32. Some code uses the upper 8 bits
of a 
presumed 32-bit long. You will need to change such code or hand-code it.

Avoid recursion. Sometimes it will work and sometimes (most of the time) it
won't. If a function requires no local storage (everything is kept in
r8-r15),
then it will work until you exceed the capabilities of the 256-byte 6502
stack
(probably real quick). Otherwise, it won't.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web