6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 7:53 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Fri Mar 10, 2017 10:41 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
I'm wondering about what choices we might have on the 6502 for compiling code on the machine itself... (so, not thinking of cc65 or WDC's C compiler or others which run on a modern machine to produce 6502 code.)

By compiler, I mean something which makes an effort to predigest a high level language for better runtime performance than a simple interpreter. By high level language, I mean something which offers more control than just branches or calls to labels, offers named functions or procedures with parameters, offers data types more interesting than just bytes.

So, I include compilers which compile down to an intermediate code which is interpreted.

In the land of Acorn's BBC Micro, there were several offerings from Acorn's own Acornsoft, usually on ROM (or multiple 16k ROMs) and needing the ROM for both compile-time and run-time: see the catalogue here (PDF)
    ISO-Pascal - compiles to intermediate code; standalone generator also available
    BCPL - compiles to intermediate code; standalone generator also available
    FORTH (an indirect threaded implementation [ref])
(capitalisation from the price list there. Also offered are Logo, LISP, micro-PROLOG, and COMAL, all interpreters, I believe.)

There was also an offering from Superior Software - Accelerator - which compiled BBC Basic to machine code via an intermediate G code. It hooked directly into routines from the Basic ROM at runtime and so was only compatible with one version of Basic.

According to this file there were also several C compilers:
Quote:
Acornsoft 'C'
This version was designed for the Master series machines, and requires
two banks of SWR and shadow ram. If you Model 'B' has been expanded to
this level, then this version of 'C' is one of the two leaders.

Beebug 'C'
This version of C has more modest demands, and hence I highly
recommend its purchase if you wish to learn C on a BBC micro. It comprises
two roms, a disk, and a manual. A further bonus is that there is an
add-on, the Stand Alone Generator, which allows your programs to run
without the roms being present.

Mijas 'C'
This comprises a disk and several manuals which contains the Small C
and the 6502 development system. This version of C generates assembler
code which is then assembled to produce 6502 machine code. It is not as
comprehensive a C as either Acornsoft's or Beebug's, but it has the
advantage of compiling down to machine code. It is a much enhanced version
of the public domain version of C. This version requires 4 banks of SWR or
the rom images blown into eproms.

Brasscourt 'C'
This comprises a rom, a disk, and a manual. Comments as for Mijas C,
but is less comprehensive.

Public Domain Tiny C
This version of C is too restrictive for serious use, but it is never
the less a reasonable introduction to C.


The same document also mentions an APL (which might be an interpreter, although that tends not to hurt APL performance much) from I-APL Ltd ("the I-APL organization was at one time working on porting their free version of APL to the Apple II (and Commodore 64)."[ref]), a FORTRAN from AJS Soft (which turns out to be an interpreter) and HALCIEN which I would guess was an interpreter too.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 10, 2017 6:43 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
Were you just looking at the BBC Micro? Or other 6502 platforms?

I'm sure there were several for the Apple. The Atari had both a C compiler (this, too, was a Small C) but it also had Action!, which was quite fast. It was a cartridge based Algol-esque language.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 10, 2017 6:49 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
At one time, the Power C compiler (not to be confused with this product), which was paired with the Buddy assembler, was available for the Commodore 64 and 128 computers. The Power C compiler predated the 1989 ANSI C standard, which means it follows the K&R syntax for things like function prototypes. I briefly looked at the C-128 version during the latter 1980s, but never did any substantial programming with it.

Similarly, Abacus Software produced a C compiler for the C-64. I don't recall if they ever produced a C-128 version.

In the realm of BASIC, Skyles Electric Works offered a very good BASIC compiler for the C-128 that produced fast-executing code, especially in the realm of number processing. I developed a graphics program with it, using BASIC to perform the floating point calculations needed to produce geometric shapes, and assembly language to do the integer math and low-level grunt work involved in driving the 8568 video display controller (VDC). BASIC's prompts and status messages were written on the 40 column display, and the graphic images appeared on the 80 column display in bitmap mode—I used two video monitors so I could see both displays at the same time. Due to the speedup experienced by the compiled BASIC code, one had the impression that the entire mess was written in assembly language.

Speaking of C, that language has never been a good fit with any of the eight bit 6502 family, mainly due to the lack of native support for managing stack frames. I have tried out the C compiler shipped in the WDC package and can report that it produces fast and efficient code on the 65C816, no doubt because the latter does support stack frames.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 10, 2017 7:04 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
whartung wrote:
Were you just looking at the BBC Micro? Or other 6502 platforms?


I'm interested in the general question, but I happened to have some familiarity with the Beeb.

I suppose in principle any offering for a 6502 machine could be ported to another... but in practice that would be rather involved.

Both the Apple and C64 had a serious RAM advantage on the Beeb, but if the Beeb can run 32k of software from ROM that might help even the balance. If the Beeb has a 64k second processor, it certainly makes a difference!

Thanks for the pointers though:
Quote:
This compiler was used to compile itself! First true language "bootstrap" on any 8-bit machine ... Compiles to 6502 code which emulates the 8080 instruction set.

- https://atariwiki.org/wiki/Wiki.jsp?page=C

BigDumbDinosaur wrote:
...Power C compiler...
... Skyles Electric Works offered a very good BASIC compiler for the C-128 ...

Thanks for those pointers too!

There's something of an advantage in a Basic compiler, if there's a large user base cranking out Basic programs, or wanting to, and needing some more performance. Especially if it has some knowledge of some particular features of the machine, like graphics or sound.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 10, 2017 7:19 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
BigEd wrote:
There's something of an advantage in a Basic compiler, if there's a large user base cranking out Basic programs, or wanting to, and needing some more performance. Especially if it has some knowledge of some particular features of the machine, like graphics or sound.

It seems that the main improvement in performance with compiled BASIC was in floating point math, most likely in the ASCII <—> FP conversion functions, which tended to be quite slow on most eight bit machines. Variable handling was improved as well. I found out some time after I had discontinued C-128 programming that the Skyles BASIC compiler used a sorted table of names, along with a binary search, to handle access to variables. Compare that to a sequential search of variable space used by Microsoft BASIC. This technique mimicked what is done in Business BASIC interpreters running on Linux and UNIX, and would have explained the substantial speedup seen in processing strings.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 10, 2017 10:35 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BigEd wrote:
I suppose in principle any offering for a 6502 machine could be ported to another... but in practice that would be rather involved.

Indeed. The source code for Action is actually available: https://sourceforge.net/projects/atari-action/

Since it included an editor (among other things), there's clearly a bunch of Atari specific code in there. But, yanking the compiler out my not be too arduous. Outside of perhaps some CIO routines to read/write from disk, the bulk of it should be pretty generic. It also included a run time library, this was bundled on the ROM cartridge. There would certainly be some Atari bits in there as well. Action ran in a 48K Atari out of a ROM. I think it was a 16K ROM, which would suggest there was perhaps some bank switching shenanigans involved somewhere.
BigDumbDinosaur wrote:
It seems that the main improvement in performance with compiled BASIC was in floating point math, most likely in the ASCII <—> FP conversion functions, which tended to be quite slow on most eight bit machines. Variable handling was improved as well. I found out some time after I had discontinued C-128 programming that the Skyles BASIC compiler used a sorted table of names, along with a binary search, to handle access to variables. Compare that to a sequential search of variable space used by Microsoft BASIC. This technique mimicked what is done in Business BASIC interpreters running on Linux and UNIX, and would have explained the substantial speedup seen in processing strings.

These are good points BDD. Now, Atari BASIC didn't do ASCII (Well, ATASCII) -> FP, save during entry. Once entered, numbers were stored internally in binary. However, the Atari didn't have the notion of integers. All numbers were in the floating point.

Variable lookup, and line number lookup were both expensive, as they were simply linear searches through their respective tables (variable table for variables, and the tokenize BASIC code for line numbers). A BASIC compiler could readily improve program performance by removing those lookups, and converting them in to absolute addresses. After that, you're effectively in a tokenized interpreter, which can be quite fast (reference all the Forth discussion). On BASIC XL, for the Atari, the FAST command would run through the program and resolve the line numbers, and that alone provided a pretty dramatic speedup to the program.

It's easy to see a solid improvement to a BASIC that, indeed, stored their numbers (within the source code) in ASCII. Having those constants precomputed would certainly speed things up.

Converting the BASIC code to actual machine code likely wasn't worth the trouble.


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 11, 2017 4:07 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1918
Location: Sacramento, CA, USA
David Schmenk has done some nice work in PLASMA, which is 8-bit Apple-specific, but has had some porting activity:

search.php?keywords=plasma+schmenk&terms=all&author=&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Search

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 11, 2017 4:41 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Good point!
Quote:
PLASMA is a medium level programming language targeting the 8-bit 6502 processor.
PLASMA is a combination of virtual machine and assembler/compiler matched closely to the 6502 architecture. ... the compiler can be very simple and ... self-hosted...

What's more, there's an effort underway to port it to the Beeb. Which might result in something which is in turn easier to port to other machines.


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 12, 2017 3:35 am 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 119
Location: Lake Tahoe
BigEd wrote:
Good point!
Quote:
PLASMA is a medium level programming language targeting the 8-bit 6502 processor.
PLASMA is a combination of virtual machine and assembler/compiler matched closely to the 6502 architecture. ... the compiler can be very simple and ... self-hosted...

What's more, there's an effort underway to port it to the Beeb. Which might result in something which is in turn easier to port to other machines.

I had no idea they were doing this. Just made my day. The PLASMA VM isn't tied too directly to the Apple II. I've built versions for the Apple I and the Apple /// without much effort. The IDE is a bit of a hack job, though. It doesn't use relocatable modules and is just a big, ugly, monolithic blob that contains the editor, compiler, and runtime all together. It was written early on, before all the relocatable module stuff was solidified to prove it could be done (it only uses the main 64K, none of the banked memory). It still gives you about 16K of code space and about 8K of compiled code space to play with. Someday I should rewrite it as modules it which will get the banked memory support involved.

Kudos to the Beeb team.

Dave...


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 20, 2017 1:00 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
I think the non existing "common platform" (like CP/M for example) is the main cause for the lack of such compilers.
If one would "define" a minimal platform - say 32KiB RAM from 0..$7FFF, a set of vectors to system dependent subroutines like outchar, inchar, checkbreak, save and load - it could be possible to write some (limited) compilers for such a platform. But who wants to use such a primitive solution, having an Apple/Atari/Acorn/etc. ? All their capabilities weren´t used - that doesn´t look appealing.

Looks like a doom-loop to me :(


Top
 Profile  
Reply with quote  
PostPosted: Thu May 11, 2017 3:22 pm 
Offline

Joined: Thu Feb 10, 2011 3:14 am
Posts: 79
I've had a C-style language optimized for the 6502 on the back burner for years. In the last month I've started making serious progress on it. I hope to make it public in the next month or so.

I'm trying to design the standard libraries to allow cross-platform compatibility.

It's currently written in standard C, but I have written the code in such a way that it can be easily converted with the goal of compiling the compiler into 6502 code.


Top
 Profile  
Reply with quote  
PostPosted: Sun May 21, 2017 7:21 pm 
Offline

Joined: Sun Feb 23, 2014 2:43 am
Posts: 78
I first started learning C using "Super-C" on the C64 (by Abacus), with one of Herb Schildt's books in-hand. It had a nice text editor, assembler, linker etc. The biggest drawback was disk-swapping, but in the end I was very pleased to render Mandelbrots a little faster, and learn a new language in the process.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: