6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Jun 16, 2024 3:03 am

All times are UTC




Post new topic Reply to topic  [ 89 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Author Message
PostPosted: Thu Oct 12, 2017 7:04 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
barrym95838 wrote:
https://github.com/dschmenk/PLASMA/

I haven't tried it yet, but it looks like the talented Mr. Schmenk is on to something nice here.

Mike B.


Also worth noting, the very recent COWGOL from David Given:
Quote:
I am very pleased, gleeful even, to announce the first proper release of Cowgol, my almost self hosted fully compiled, properly strongly typed, Ada-inspired programming language for the 6502! Which is written in Cowgol itself!

https://github.com/davidgiven/cowgol

- http://stardot.org.uk/forums/viewtopic.php?f=53&t=13871


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 12, 2017 3:43 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
Wow -- that's really exciting.


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 15, 2017 8:08 pm 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 126
Location: Lake Tahoe
White Flame wrote:
PLASMA is a VM, so if the point is to get high speed, which is usually why C is chosen over other HLLs, I don't think that's the direction to take. VMs are great for code density, though.

PLASMA currently targets the VM, but it didn't always. The first version:
(http://vm02.cvs.sourceforge.net/viewvc/ ... 02/plasma/)
could generate three different outputs: byte code, threaded code, and in-line native. The in-line code was quite fast, but as noted earlier, the 6502 isn't the most efficient compiler target, so it was a great deal larger. So later versions targeted just the byte code with an eye towards an efficient interpreter and the ability to execute byte code out of auxiliary/extended memory.

As for high speed, that can be subjective. PLASMA is certainly faster than BASIC, and is roughly equivalent to Forth (I used many concepts from Forth's interpreter when designing PLASMA's VM). The cc65 C compiler implements much of its functionality through library calls to keep the code size reasonable. Each call takes 12 cycles just for JSR/RTS and I have the inner loop for the VM down to 16 cycles. Not insignificant, but the code density and ability to have byte code in auxiliary memory was a good tradeoff, IMHO.

My eventual goal is to create a JIT to target 6502/65C02 which may or may not happen in my lifetime. However, whichever HLL compiler to implement on a 6502, it seems to me that an intermediate representation that satisfies the requirements of implementing the HLL constructs while still fitting into the constraints of the 6502 is crucial. I just went through a re-write of the compiler to extract out the optimizer into an optional back-end operation. This greatly simplified the main code generator and allowed for much better optimizations to occur (with great help from SteveF: http://stardot.org.uk/forums/viewtopic. ... 88#p163288)

Although I've programmed professionally in C for 33 years, I find PLASMA to be much more productive on the 6502 than any other language (Ok, so I'm a little biased). I will still write a number of performance critical routines in 6502 assembly (easy to write assembly routines inside PLASMA) but quite honestly, 100% of the code I write doesn't have to be the fastest possible.


Dave...


Last edited by resman on Sun Oct 15, 2017 9:01 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 15, 2017 8:29 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
One thing strikes me: the most efficient data type on 6502 is the byte - especially for counters. So a language which defaults to byte-size data, or at least makes it easy (and tidy) to declare data to be byte size, would be a win. Perhaps the best possible situation is where the compiler can infer that a byte-size operation is sufficient, without annotations.

(I say this without checking how PLASMA or any other language tackles the problem...)


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 15, 2017 8:48 pm 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 126
Location: Lake Tahoe
BigEd wrote:
One thing strikes me: the most efficient data type on 6502 is the byte - especially for counters. So a language which defaults to byte-size data, or at least makes it easy (and tidy) to declare data to be byte size, would be a win. Perhaps the best possible situation is where the compiler can infer that a byte-size operation is sufficient, without annotations.

(I say this without checking how PLASMA or any other language tackles the problem...)

PLASMA has two basic data types: byte (unsigned 8 bits) and word (signed 16 bits). That's all you could ever need!


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 15, 2017 8:50 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
Sounds good!


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 15, 2021 8:50 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8458
Location: Southern California
GARTHWILSON wrote:
I would really like for someone to improve upon cc65. As it is, it generates horribly inefficient code. Anyone with any experience at all can do much better in assembly.

I just came across this page about benchmarking the various C compilers for the 6502. CC65 produced much slower, more bloated code than the other C options, although it was more solid.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 15, 2021 6:03 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8214
Location: Midwestern USA
GARTHWILSON wrote:
GARTHWILSON wrote:
I would really like for someone to improve upon cc65. As it is, it generates horribly inefficient code. Anyone with any experience at all can do much better in assembly.

I just came across this page about benchmarking the various C compilers for the 6502. CC65 produced much slower, more bloated code than the other C options, although it was more solid.

I saw that page as well. It succeeds in pointing out the gorilla in the room, which is the 65(c)02 is not a compiler-friendly MPU. The 65C816 is much better suited to C, although still hampered by its paucity of general purpose registers.

EDIT: Fixed some phrasing that evidently was misunderstood by several readers.

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


Last edited by BigDumbDinosaur on Mon Aug 16, 2021 1:40 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 15, 2021 6:10 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
Complete nonsense, BDD. I hope you never behave like this in person.

It's a comparison of various aspects of various compilers, shows a lot of care and attention, and is worth a read: title is "Technical highlight: C compilers for 6502 benchmark: A new hope!"

Some images from within:

Image

Image

Image

Image


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 15, 2021 6:39 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8214
Location: Midwestern USA
What is complete nonsense?

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 15, 2021 7:56 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3366
Location: Ontario, Canada
BigDumbDinosaur wrote:
What is complete nonsense?
Accidentally or otherwise, BDD, in your post you imply the article has little or no value. I'm guessing that's what Ed considers nonsense.

(Just sayin'. I don't have an opinion, myself -- about the article, I mean. But the excerpts posted do seem comprehensive.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 16, 2021 6:07 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8214
Location: Midwestern USA
Dr Jefyll wrote:
BigDumbDinosaur wrote:
What is complete nonsense?
Accidentally or otherwise, BDD, in your post you imply the article has little or no value. I'm guessing that's what Ed considers nonsense.

(Just sayin'. I don't have an opinion, myself -- about the article, I mean. But the excerpts posted do seem comprehensive.)

-- Jeff

That wasn't at all what I intended. The article was interesting. I was referring to the 6502 not being a good compiler target.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 23, 2021 3:43 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8458
Location: Southern California
I came across this on another forum, another C compiler for the '02:
https://drive.google.com/file/d/1Eai87N ... DAyx0/view

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 23, 2021 7:56 am 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 694
Location: North Tejas
GARTHWILSON wrote:
I came across this on another forum, another C compiler for the '02:
https://drive.google.com/file/d/1Eai87N ... DAyx0/view

Thanks for that.

Though I have no interest in programming the 6502 family in C or writing a C compiler, the manual is interesting reading as to ideas for generating good code for the 6502.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 89 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

All times are UTC


Who is online

Users browsing this forum: No registered users and 29 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: