| 6502 unsuitable for use with compiled languages? [message #300845] |
Sun, 20 September 2015 19:25  |
Andreas Kohlbach
Messages: 1456
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Not strictly Commodore related, and although many Commodore computers used
the 6510 I would assume the stated problems would also target it.
Like most of you I enjoy nostalgia. And often read old magazines. Like
the BYTE February 1984 now, which is all about benchmarks (besides
introducing a brand new computer called Macintosh ;-).
Towards the end of that issue they test Pascal compilers. While reading
this I stumbled across the following paragraph:
| If compilers offer so many advantages over assemblers and interpreters,
| then why aren't compiled languages more common in the microcomputer
| world? Unfortunately, many of the early microprocessors, such as the
| 6502, are unsuitable for use with compiled languages. In particular,
| the limited stack and lack of 16-bit arithmetic on the 6502 make it
| hard to write a good compiler for that machine. Just five distinct
| high-level languages for the Apple II Pascal, FORTH, BASIC, Sweet 16,
| and FORTRAN are available, according to a BYTE article by Jim Gilbreath
| and Gary Gilbreath [...]. It is not known how many of these languages
| are compiled, but from the fact that these languages are between 10 and
| 200 times slower than 6502 assembly language, it is apparent that the
| 6502 is not the machine of choice for high-level languages.
But is that really true that only five languages were available for the
6502? And would other 8-bit CPU have the same issues then?
--
Andreas
I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.
|
|
|
|
| Re: 6502 unsuitable for use with compiled languages? [message #300903 is a reply to message #300845] |
Mon, 21 September 2015 18:52  |
Dombo
Messages: 210
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Op 21-Sep-15 om 1:25 schreef Andreas Kohlbach:
> Not strictly Commodore related, and although many Commodore computers used
> the 6510 I would assume the stated problems would also target it.
>
> Like most of you I enjoy nostalgia. And often read old magazines. Like
> the BYTE February 1984 now, which is all about benchmarks (besides
> introducing a brand new computer called Macintosh ;-).
>
> Towards the end of that issue they test Pascal compilers. While reading
> this I stumbled across the following paragraph:
>
> | If compilers offer so many advantages over assemblers and interpreters,
> | then why aren't compiled languages more common in the microcomputer
> | world? Unfortunately, many of the early microprocessors, such as the
> | 6502, are unsuitable for use with compiled languages. In particular,
> | the limited stack and lack of 16-bit arithmetic on the 6502 make it
> | hard to write a good compiler for that machine. Just five distinct
> | high-level languages for the Apple II Pascal, FORTH, BASIC, Sweet 16,
> | and FORTRAN are available, according to a BYTE article by Jim Gilbreath
> | and Gary Gilbreath [...]. It is not known how many of these languages
> | are compiled, but from the fact that these languages are between 10 and
> | 200 times slower than 6502 assembly language, it is apparent that the
> | 6502 is not the machine of choice for high-level languages.
>
> But is that really true that only five languages were available for the
> 6502?
I don't know exactly the year but at some point there was also a C
compiler for the 6502.
> And would other 8-bit CPU have the same issues then?
Not necessarily as bad as the 6502. For example the Z80:
- Has a stack that is _not_ limited to 256 bytes;
- Can treat two 8-bit registers as a single 16-bit register;
- Can perform (limited) 16-bit arithmetic directly;
- Can use the 16-bit registers as memory address for other instructions;
- Has useful index + offset addressing modes.
Those things make a difference for programming languages like C.
Another example is the Atmel AVR 8-bit micro-controller family. These
micro-controllers are often programmed using the C language. Atmel
claims the the instruction set of these micro-controllers were designed
with the C programming language in mind. My experience is that the Atmel
AVR 8-bit C compiler does do a reasonable job as long as you remember
you are targeting a 8-bit device; you should use 8-bit data types
wherever possible and only use integers (which are required by the C
standard to be at least 16 bits) if you really have to. Otherwise the
compiler would produce rather inefficient code compared to handcrafted
assembly code.
|
|
|
|
| Re: 6502 unsuitable for use with compiled languages? [message #300929 is a reply to message #300845] |
Tue, 22 September 2015 07:38 |
Richard
Messages: 13
Registered: April 2012
Karma: 0
|
Junior Member |
|
|
Am 2015-09-21 um 01:25 schrieb Andreas Kohlbach:
> But is that really true that only five languages were available for
> the 6502? And would other 8-bit CPU have the same issues then?
Quickly from my mind: C, Pascal, Comal, Ada (well, a subset), Basic.
Seems realistic...
I used C and Pascal on the C64, and in each case both the compilers and
the resulting code were very slow compared to assemblers and machine
code. In all cases it would have been a better idea to just use built-in
Basic with some supporting assembly language code for the time-critical
parts.
The 6502 is especially bad at pointer handling, since it can only handle
8 bit at a time, and memory addresses are 16 bit. Also, in order to to
dereference pointers, they have to be copied into the zero page first.
This is especially bad for the C programming language which relies
heavily on pointer arithmetics.
I think, a relatively efficient high-level programming languages for the
6502 would have to contain special language features to allow the
programmer to make use of efficient indexed addressing modes and to use
static instead of dynamic (stack-based) memory allocation. Nevertheless,
due to the limited number of registers and the irregularity of the
instruction set, it would still produce code which is a lot less
efficient than hand-written assembly code.
Richard
|
|
|
|
| Re: 6502 unsuitable for use with compiled languages? [message #300945 is a reply to message #300845] |
Tue, 22 September 2015 11:25 |
Martijn van Buul
Messages: 326
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
* Andreas Kohlbach:
> But is that really true that only five languages were available for the
> 6502? And would other 8-bit CPU have the same issues then?
It's tricky for a lot of 8-bit CPUs, but some are trickier than others.
A long time ago (as in: 1999 - 2002), I worked for Philips Semiconductors
(now NXP), doing technical support on their line microcontrollers based
on the 8051 core. While there are several C compilers available, both
commercial as well as open source), the result never really impressed me,
and I've always felt that those compilers were doing more harm than they
really did good. A large part of my daily job boiled down to showing customers
that their software would work provided they redid a lot of their work in
assembly. And I wouldn't be overly surprised if a large part of them ended up
using an Atmel AVR.
The 8051 architecture is mildly bizarre at places (There are no less than
*six* address spaces[1], some of them with conflicting addressing), resulting
in very weird non-standard additions to the C language just to make things
work. In a way, it's even LESS suitable to C (for example) than the 6502 ever
was. But here comes the rub:
It is my firm belief that the main reason that there are somewhat functional C
compilers for the 8051 available lies in the fact that the 8051 is *so pants*
that you can't really use it for anything that requires more than a few bytes
of memory anyway. The fact that it only has 128 bytes of directly accessible
RAM makes a lot of the regular arguments against compiled languages on 8-bit
CPUs moot... Also, The fact that the 8051 was an industry standard makes
creating a compiler for it a decent business, even when it is technically
challenging.
So, yeah. The 6502 doesn't lend it self to compiled languages. But the
fact that other CPUs *may* have a compiler doesn't necessarily mean they
are, it's just more financially worthwhile to develop them :)
Martijn.
[1] It's strictly harvard, separating data and instructions, so you end up
with
1. Program memory, which is distinct from data. 64KB, only accessible
using indirect addressing. No write access.
2. Internal RAM, directly accessible. 128 bytes.
3. Internal RAM, only indirectly accessible. 128 bytes.
4. Special Function Registers (For all intents and purposes: I/O,
although some of the processor registers are implemented as an SFR)
Overlaps the top 128 bytes of Internal RAM, using the same addresses.
*some* opcodes will use SFRs, *some* will use IRAM instead. Great fun.
5. Some (well, 16 bytes) of the IRAM is bitwise addressable, so IRAM
byte 0x20 corresponds to bit address 0 through 8. The first 16 bytes
of the SFRs are also bit-addressable, but as they are defined by
hardware they don't require special consideration.
6. "External RAM", or XRAM, 64KB, only accessible indirectly, using
a single datapointer register (shared with PMEM acess). About as
useful as general purpose memory as the VDC's memory on the C128.
The most useful application of it was to (externally) combine it
with program memory, because this was *the only way* to actually
load a program to be executed into memory.
And then I haven't even touched the fact that most of the internal
internal registers are merely aliases for locations in IRAM. Of course,
it's in the scarce first part of IRAM. Figures.
When I was left, scuttlebutt had it that there was a new core in the
works (the 8051XM, not to be confused with the XA), which added a
seventh memory space (which would contain aliases of the other 6),
extending the addressable range to 16 MB. I never heard anything of it
anymore. This was just prior of the dissolution of Philips
Semiconductors into NXP, and my best guess is that it got axed in the
process.
--
Martijn van Buul - pino@dohd.org
|
|
|
|
| Re: 6502 unsuitable for use with compiled languages? [message #300964 is a reply to message #300929] |
Tue, 22 September 2015 18:01 |
James Harris
Messages: 31
Registered: March 2013
Karma: 0
|
Member |
|
|
"Richard" <portempa@aon.at> wrote in message
news:56013da2$0$303$14726298@news.sunsite.dk...
> Am 2015-09-21 um 01:25 schrieb Andreas Kohlbach:
>
>> But is that really true that only five languages were available for
>> the 6502? And would other 8-bit CPU have the same issues then?
....
> The 6502 is especially bad at pointer handling, since it can only
> handle
> 8 bit at a time, and memory addresses are 16 bit. Also, in order to to
> dereference pointers, they have to be copied into the zero page first.
> This is especially bad for the C programming language which relies
> heavily on pointer arithmetics.
Absolutely. The need for zero-page locations to allow indexing off Y
would require that the compiler know which of those locations it could
use, i.e. which were not already allocated by the CBM OS.
Re. other CPUs of the time, the Z80 was far better at pointer handling.
IIRC it allowed HL and DE to contain full 16-bit pointers.
James
|
|
|
|
| Re: 6502 unsuitable for u [message #300971 is a reply to message #300903] |
Mon, 21 September 2015 16:42 |
|
|
Originally posted by: removemefirst.Ed.Vance
09-22-15 00:52 Dombo wrote to All about Re: 6502 unsuitable for u
Howdy! Dombo,
Do> @MSGID: <56013001.1058.cbm@capcity2.synchro.net>
Do> @REPLY: <55FFDE82.1057.cbm@capcity2.synchro.net>
Do> Op 21-Sep-15 om 1:25 schreef Andreas Kohlbach:
> Not strictly Commodore related, and although many Commodore computers used
> the 6510 I would assume the stated problems would also target it.
>
> Like most of you I enjoy nostalgia. And often read old magazines. Like
> the BYTE February 1984 now, which is all about benchmarks (besides
> introducing a brand new computer called Macintosh ;-).
>
> Towards the end of that issue they test Pascal compilers. While reading
> this I stumbled across the following paragraph:
>
> | If compilers offer so many advantages over assemblers and interpreters,
> | then why aren't compiled languages more common in the microcomputer
> | world? Unfortunately, many of the early microprocessors, such as the
> | 6502, are unsuitable for use with compiled languages. In particular,
> | the limited stack and lack of 16-bit arithmetic on the 6502 make it
> | hard to write a good compiler for that machine. Just five distinct
> | high-level languages for the Apple II Pascal, FORTH, BASIC, Sweet 16,
> | and FORTRAN are available, according to a BYTE article by Jim Gilbreath
> | and Gary Gilbreath [...]. It is not known how many of these languages
> | are compiled, but from the fact that these languages are between 10 and
> | 200 times slower than 6502 assembly language, it is apparent that the
> | 6502 is not the machine of choice for high-level languages.
>
> But is that really true that only five languages were available for the
> 6502?
Do> I don't know exactly the year but at some point there was also
Do> a C compiler for the 6502.
The POWER C software made by BetterWorking from Spinnaker Software
Corp. has a Copyright Date of 1986 on the box.
The box says it's a "disk based true C language compiler for the
Commodore computers.".
Is that the compiler You were thinking about?
And speaking of the Apple ][ , I've seen a C=64 PRG that some Apple ][
BASIC Programs could be ran with.
I can't remember if the PRG was called a Apple ][ Emulator or what.....
.... A KGB keyboard has no ESC key.
--- MultiMail/MS-DOS v0.49
|
|
|
|
| Re: 6502 unsuitable for use with compiled languages? [message #300991 is a reply to message #300845] |
Wed, 23 September 2015 00:08 |
dott.Piergiorgio
Messages: 166
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Il 21/09/2015 01:25, Andreas Kohlbach ha scritto:
> Not strictly Commodore related, and although many Commodore computers used
> the 6510 I would assume the stated problems would also target it.
>
> Like most of you I enjoy nostalgia. And often read old magazines. Like
> the BYTE February 1984 now, which is all about benchmarks (besides
> introducing a brand new computer called Macintosh ;-).
>
> Towards the end of that issue they test Pascal compilers. While reading
> this I stumbled across the following paragraph:
>
> | If compilers offer so many advantages over assemblers and interpreters,
> | then why aren't compiled languages more common in the microcomputer
> | world? Unfortunately, many of the early microprocessors, such as the
> | 6502, are unsuitable for use with compiled languages. In particular,
> | the limited stack and lack of 16-bit arithmetic on the 6502 make it
> | hard to write a good compiler for that machine. Just five distinct
> | high-level languages for the Apple II Pascal, FORTH, BASIC, Sweet 16,
> | and FORTRAN are available, according to a BYTE article by Jim Gilbreath
> | and Gary Gilbreath [...]. It is not known how many of these languages
> | are compiled, but from the fact that these languages are between 10 and
> | 200 times slower than 6502 assembly language, it is apparent that the
> | 6502 is not the machine of choice for high-level languages.
>
> But is that really true that only five languages were available for the
> 6502? And would other 8-bit CPU have the same issues then?
on C language, the main issue lies in the heavy usage of the stack of
the compiled programs, esp. in calling subroutines and passing
parameters. subr (char a,b,c,d,e) generates at least seven pushes
(return address, and the values of the five byte variables. too easy to
overflow the fixed 256 byte stack of 65xx architecture, I suppose.)
an quick example of code generated from a 65xx C compiler (*nix cc65
x-compiler):
> ;
> ; sub (a,b,c,d,e);
> ;
> jsr decsp5
> ldy #$04
> ldx #$00
> lda (sp),y
> ldx #$00
> jsr pushax
> ldy #$05
> ldx #$00
> lda (sp),y
> ldx #$00
> jsr pushax
> ldy #$06
> ldx #$00
> lda (sp),y
> ldx #$00
> jsr pushax
> ldy #$07
> ldx #$00
> lda (sp),y
> ldx #$00
> jsr pushax
> ldy #$08
> ldx #$00
> lda (sp),y
> ldx #$00
> jsr pushax
> jsr _sub
Best regards from Italy,
dott. Piergiorgio.
|
|
|
|
| Re: 6502 unsuitable for use with compiled languages? [message #301014 is a reply to message #300991] |
Wed, 23 September 2015 09:19 |
Anton Treuenfels
Messages: 105
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
"dott.Piergiorgio" <dott.piergiorgio@gmail.com> wrote in message
news:mtt8gs$8pl$1@dont-email.me...
> Il 21/09/2015 01:25, Andreas Kohlbach ha scritto:
>> Not strictly Commodore related, and although many Commodore computers
>> used
>> the 6510 I would assume the stated problems would also target it.
>>
>> Like most of you I enjoy nostalgia. And often read old magazines. Like
>> the BYTE February 1984 now, which is all about benchmarks (besides
>> introducing a brand new computer called Macintosh ;-).
>>
>> Towards the end of that issue they test Pascal compilers. While reading
>> this I stumbled across the following paragraph:
>>
>> | If compilers offer so many advantages over assemblers and interpreters,
>> | then why aren't compiled languages more common in the microcomputer
>> | world? Unfortunately, many of the early microprocessors, such as the
>> | 6502, are unsuitable for use with compiled languages. In particular,
>> | the limited stack and lack of 16-bit arithmetic on the 6502 make it
>> | hard to write a good compiler for that machine. Just five distinct
>> | high-level languages for the Apple II Pascal, FORTH, BASIC, Sweet 16,
>> | and FORTRAN are available, according to a BYTE article by Jim Gilbreath
>> | and Gary Gilbreath [...]. It is not known how many of these languages
>> | are compiled, but from the fact that these languages are between 10 and
>> | 200 times slower than 6502 assembly language, it is apparent that the
>> | 6502 is not the machine of choice for high-level languages.
>>
>> But is that really true that only five languages were available for the
>> 6502? And would other 8-bit CPU have the same issues then?
>
> on C language, the main issue lies in the heavy usage of the stack of the
> compiled programs, esp. in calling subroutines and passing parameters.
> subr (char a,b,c,d,e) generates at least seven pushes (return address, and
> the values of the five byte variables. too easy to overflow the fixed 256
> byte stack of 65xx architecture, I suppose.)
>
> an quick example of code generated from a 65xx C compiler (*nix cc65
> x-compiler):
>
>> ;
>> ; sub (a,b,c,d,e);
>> ;
>> jsr decsp5
>> ldy #$04
>> ldx #$00
>> lda (sp),y
>> ldx #$00
>> jsr pushax
>> ldy #$05
>> ldx #$00
>> lda (sp),y
>> ldx #$00
>> jsr pushax
>> ldy #$06
>> ldx #$00
>> lda (sp),y
>> ldx #$00
>> jsr pushax
>> ldy #$07
>> ldx #$00
>> lda (sp),y
>> ldx #$00
>> jsr pushax
>> ldy #$08
>> ldx #$00
>> lda (sp),y
>> ldx #$00
>> jsr pushax
>> jsr _sub
>
> Best regards from Italy,
> dott. Piergiorgio.
>
>
That is horrible code. I know many people like cc65, but it appears that it
doesn't do even simple peephole optimization.
- Anton Treuenfels
|
|
|
|
|
|
| Re: 6502 unsuitable for u [message #301090 is a reply to message #301015] |
Wed, 23 September 2015 06:34 |
|
|
Originally posted by: removemefirst.Ed.Vance
09-23-15 06:47 Chris "xc8" wrote to Ed Vance about Re: 6502 unsuitable for u
Howdy! Chris,
C"> @MSGID: <5603233B.1065.cbm@capcity2.synchro.net>
C"> On Wednesday, 23 September 2015 01:36:12 UTC+1, Ed Vance
C"> wrote:
>
> And speaking of the Apple ][ , I've seen a C=64 PRG that some Apple ][
> BASIC Programs could be ran with.
>
> I can't remember if the PRG was called a Apple ][ Emulator or what.....
>
C"> Appsoft-64 (AppleSoft)
C"> http://members.optusnet.com.au/spacetaxi64/MAIN/64EMU.htm
Yeah, Applesoft sounds like the PRG's name, don't remember the 64
though.
Will have to look through the directory print outs that I made for some
of my floppies, to be sure of what the PRG that I have is called.
iirc I typed it in from a RUN booklet, I'll let You know what I learn
about it when I find out.
.... Why does something unexpected happen when I use a computer?
--- MultiMail/MS-DOS v0.49
|
|
|
|
| Re: 6502 unsuitable for u [message #301091 is a reply to message #301015] |
Wed, 23 September 2015 07:25 |
|
|
Originally posted by: removemefirst.Ed.Vance
09-23-15 06:47 Chris "xc8" wrote to Ed Vance about Re: 6502 unsuitable for u
Howdy! again Chris,
C"> @MSGID: <5603233B.1065.cbm@capcity2.synchro.net>
C"> On Wednesday, 23 September 2015 01:36:12 UTC+1, Ed Vance
C"> wrote:
>
> And speaking of the Apple ][ , I've seen a C=64 PRG that some Apple ][
> BASIC Programs could be ran with.
>
> I can't remember if the PRG was called a Apple ][ Emulator or what.....
>
C"> Appsoft-64 (AppleSoft)
C"> http://members.optusnet.com.au/spacetaxi64/MAIN/64EMU.htm
A disk I have has a 9 Block APPLE BOOT PRG that is loaded ,8,1 then
it loads a 46 Block APPLESOFT CODE PRG.
While the APPLESOFT CODE program is loading the screen shows what CBM
KEYWORDS are substituted for some Apple Commands.
Also on that screen is APPLESOFT BASIC FOR THE COMMODORE 64 and
COMMOWARE BY DAVID YOUNG.
When the APPLESOFT CODE PRG finishes loading, I press a key and the
screen says:
APPLE ][
By David Young
Also on Side 1 of the disk I have several programs that I entered in.
On the other side of the floppy disk I have a 17 Block SEQ file called
APPLE SEQ FILES that has a bunch of Apple BASIC Listings.
Also there is a 1 Block PRG called CONVERTOR AP/C that when I LOAD and
LIST it, it shows a Chart I made to show CBM BASIC Keywords to Apple ][
BASIC Keywords.
I made that PRG in January 1988.
That's All I Know Folks!
You were right Chris, that the program is called APPLESOFT, Thanks!
.... Never invite a vampire in for a bite.
--- MultiMail/MS-DOS v0.49
|
|
|
|
Members
Search
Help
Register
Login
Home
