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

Groups > comp.lang.forth > #57042 > unrolled thread

6502 anyone ?

Back to article view | Back to comp.lang.forth

Contents

  6502 anyone ? john <anon@example.com> - 2017-04-11 13:07 +0100
    Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-11 23:31 -0400
      Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-12 01:27 -0700
        Re: 6502 anyone ? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 10:46 +0200
          Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-12 01:57 -0700
            Re: 6502 anyone ? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:24 +0200
            Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-12 14:37 -0700
              Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-12 17:16 -0700
                Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-12 18:10 -0700
                  Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-12 23:46 -0700
                    Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 03:00 -0400
                      Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 00:37 -0700
                        Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 00:42 -0700
                          Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 12:57 -0400
                            Re: 6502 anyone ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 12:01 -0500
                              Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 10:42 -0700
                                Re: 6502 anyone ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 12:55 -0500
                                  Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 11:13 -0700
                                    Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 14:24 -0400
                                      Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 11:57 -0700
                                        Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 15:15 -0400
                                Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 14:23 -0400
          Re: 6502 anyone ? john <anon@example.com> - 2017-04-12 10:25 +0100
          Re: 6502 anyone ? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-12 12:27 +0200
            Re: 6502 anyone ? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:53 +0200
              Re: 6502 anyone ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-12 12:55 +0000
                Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-12 12:20 -0400
            Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-12 05:10 -0700
              Re: 6502 anyone ? Michael Barry <barrym95838@yahoo.com> - 2017-04-12 22:41 -0700
            Re: 6502 anyone ? Joel Rees <joel.rees@gmail.com> - 2017-04-13 02:14 -0700
              Re: 6502 anyone ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-13 11:01 +0000
                Re: 6502 anyone ? jim.brakefield@ieee.org - 2017-04-13 06:33 -0700
                  Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-13 07:24 -0700
                    Re: 6502 anyone ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 09:51 -0500
                      Re: 6502 anyone ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-13 17:16 +0000
                        Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-13 13:08 -0700
                Re: 6502 anyone ? Joel Rees <joel.rees@gmail.com> - 2017-04-14 08:06 -0700
              Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 13:00 -0400
        Re: 6502 anyone ? "HAA" <someone@microsoft.com> - 2017-04-13 10:42 +1000
          Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-12 18:45 -0700
            Re: 6502 anyone ? "HAA" <someone@microsoft.com> - 2017-04-14 13:01 +1000
              Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-14 01:21 -0400
              Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-13 23:23 -0700
      Re: 6502 anyone ? john <anon@example.com> - 2017-04-12 10:08 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#57255

On 4/13/2017 2:57 PM, lehs wrote:
> I was discussing programming and wrote that AI-programming is a technique. It's not alchemistry or something, just smart technique build upon scientific results - often with astounding results. There is no computer science dealing with the mind.
>
> What is mind? I ask you what is space? Time? What is anything? You can't answer such questions with descriptions of models. Models are models.
>
> Human thinking and language is about human living. You can't expect a robot experience waking up with the hed in an ashtray after been intoxicated with alcoholic the night before. Of course robots will communicate, and already does, and of course they will be able to communicate with humans in human language. But that communication would be a kind of interface communication thru some kind of protocoll.

Ok, if you say so.

So tell me, am I a human or a robot?  Can you tell?  If you can't tell, 
what is the difference?

-- 

Rick C

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

#57249

On 4/13/2017 1:42 PM, lehs wrote:
> Den torsdag 13 april 2017 kl. 19:02:01 UTC+2 skrev Andrew Haley:
>> rickman <gnuarm@gmail.com> wrote:
>>> On 4/13/2017 3:42 AM, lehs wrote:
>>>> Cont.
>>>> Since computer programs can't experience growing up as humans there is no way for it to have all this knowledge. And the ALU will never be aware of it self.
>>>
>>> Nothing you have said precludes a machine becoming self aware.  In
>>> particular the above statement is false.  Computers can and *do* learn.
>>> There have been a number of computer programs that learn from experience.
>>>
>>> http://bfy.tw/BDB2
>>
>> :-)
>>
>> I'm surprised that anybody can repeat the computers only do what
>> they're told and can't invent anything", given the recent work at
>> DeepMind with AlphaGo.  This really wasn't a brute-force tree search
>> of the kind used by chess porgrams.
>>
>> Andrew.
>
> That's a straw-man. I agree with that computers could learn, of course. But they can never experience to be humans or express human thoughts as a result of a mind.

You are using very odd phrasing.  What exactly do you mean by "they can 
never experience to be humans".  As I have said, they can't "be humans" 
in the same way an ant can't be a dog.  But there is no reason to think 
a machine can't be self aware and capable of similar thought to the 
thoughts of a human.

The statement that a machine can't "express human thoughts as a result 
of a mind" is just plain unsupportable.  You keep making claims, but 
offer nothing to support them.

-- 

Rick C

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

#57134

In article <86h91uui7d.fsf@molnjunk.nocrew.org>, lars.spam@nocrew.org 
says...
> 
> Mark Wills wrote:
> > Also, the 6502, whilst a very simple device and quite fast, has a 
> > crap instruction set and no registers.
> 
> I haven't done any serious 6502 programming, so I wouldn't know.
> Certainly, handling anything beyond 8 bits is going to be awkward, since
> it's very insistent on being an 8-bitter.
> 
> But at least the instruction set *encoding* is quite regular and
> pleasant.  I wrote my own Forth assembler for it, and it turned out to
> be very simple.

There is a 16 bit version which I think is also running forth.
In fact the people on 6502.org seem quite keen on forth.
Far more so than here it seems. 

-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

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

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

#57140

In article <86h91uui7d.fsf@molnjunk.nocrew.org>,
Lars Brinkhoff  <lars.spam@nocrew.org> wrote:
>Mark Wills wrote:
>> Also, the 6502, whilst a very simple device and quite fast, has a
>> crap instruction set and no registers.
>
>I haven't done any serious 6502 programming, so I wouldn't know.
>Certainly, handling anything beyond 8 bits is going to be awkward, since
>it's very insistent on being an 8-bitter.
>
>But at least the instruction set *encoding* is quite regular and
>pleasant.  I wrote my own Forth assembler for it, and it turned out to
>be very simple.

Indeed.
There are misconceptions about the 6502.
6502 is the purest 8-bits processor yet very powerful. The
implementation of FYSFORTH on the Apple II made it in an actually
usable piece of equipment in the Fysisch Laboratorium of the Utrecht
University.
For the chip real estate it occupies it is one of the best.

If you know the chip you realize that it has 128 16 bit registers
on the zero page. If you don't appreciate that, you're in good company,
Andrew Tannenbaum didn't realize that fact and dismissed the 6502
as a potential target for a c-compiler.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57142

Albert van der Horst wrote:
> If you know the chip you realize that it has 128 16 bit registers on
> the zero page.

Of course proper use of the zero page is important in 6502 programming.
But can you honestly call them registers?  They reside in external RAM,
so that's goes against the regular meaning of registers.  If you ignore
that implementation detail, the programming model still don't expose
them as 16-bit register-like entities.  You can only deal with chunks of
8 bits at a time.

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

#57150

Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Albert van der Horst wrote:
>> If you know the chip you realize that it has 128 16 bit registers on
>> the zero page.
>
>Of course proper use of the zero page is important in 6502 programming.
>But can you honestly call them registers?  They reside in external RAM,
>so that's goes against the regular meaning of registers.  If you ignore
>that implementation detail, the programming model still don't expose
>them as 16-bit register-like entities.  You can only deal with chunks of
>8 bits at a time.

Right.  And you have to always go through one of the real registers to
get something there or out of there.  The only register-like quality
the zero page had was that you could use two-byte units for
addressing, similar to index or address registers in other CPUs.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#57155

On 4/12/2017 8:55 AM, Anton Ertl wrote:
> The only register-like quality
> the zero page had was that you could use two-byte units for
> addressing, similar to index or address registers in other CPUs.

Isn't that the important part that is otherwise missing in the 6502?

-- 

Rick C

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

#57149

On Wednesday, 12 April 2017 11:26:32 UTC+1, Albert van der Horst  wrote:
> In article <86h91uui7d.fsf@molnjunk.nocrew.org>,
> Lars Brinkhoff  <lars.spam@nocrew.org> wrote:
> >Mark Wills wrote:
> >> Also, the 6502, whilst a very simple device and quite fast, has a
> >> crap instruction set and no registers.
> >
> >I haven't done any serious 6502 programming, so I wouldn't know.
> >Certainly, handling anything beyond 8 bits is going to be awkward, since
> >it's very insistent on being an 8-bitter.
> >
> >But at least the instruction set *encoding* is quite regular and
> >pleasant.  I wrote my own Forth assembler for it, and it turned out to
> >be very simple.
> 
> Indeed.
> There are misconceptions about the 6502.
> 6502 is the purest 8-bits processor yet very powerful. The
> implementation of FYSFORTH on the Apple II made it in an actually
> usable piece of equipment in the Fysisch Laboratorium of the Utrecht
> University.
> For the chip real estate it occupies it is one of the best.
> 
> If you know the chip you realize that it has 128 16 bit registers
> on the zero page. If you don't appreciate that, you're in good company,
> Andrew Tannenbaum didn't realize that fact and dismissed the 6502
> as a potential target for a c-compiler.
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Meh. I don't see them as registers. I see them as operands.

1) They're in RAM
2) They're still 8 bit.

Do anything in more than 8 bits SUCKS on the 6502!

They are surprisingly fast though given all the thrashing it has to
do (8 bits, and only three registers).

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

#57212

On Wednesday, April 12, 2017 at 5:10:36 AM UTC-7, Mark Wills wrote:
> On Wednesday, 12 April 2017 11:26:32 UTC+1, Albert van der Horst  wrote:
> > In article <************>,
> > Lars Brinkhoff  <************> wrote:
> > >Mark Wills wrote:
> > >> Also, the 6502, whilst a very simple device and quite fast, has a
> > >> crap instruction set and no registers.
> > >
> > >I haven't done any serious 6502 programming, so I wouldn't know.
> > >Certainly, handling anything beyond 8 bits is going to be awkward, since
> > >it's very insistent on being an 8-bitter.
> > >
> > >But at least the instruction set *encoding* is quite regular and
> > >pleasant.  I wrote my own Forth assembler for it, and it turned out to
> > >be very simple.
> > 
> > Indeed.
> > There are misconceptions about the 6502.
> > 6502 is the purest 8-bits processor yet very powerful. The
> > implementation of FYSFORTH on the Apple II made it in an actually
> > usable piece of equipment in the Fysisch Laboratorium of the Utrecht
> > University.
> > For the chip real estate it occupies it is one of the best.
> > 
> > If you know the chip you realize that it has 128 16 bit registers
> > on the zero page. If you don't appreciate that, you're in good company,
> > Andrew Tannenbaum didn't realize that fact and dismissed the 6502
> > as a potential target for a c-compiler.
> > 
> > Groetjes Albert
> > -- 
> > Albert van der Horst, UTRECHT,THE NETHERLANDS
> > Economic growth -- being exponential -- ultimately falters.
> > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
> 
> Meh. I don't see them as registers. I see them as operands.
> 
> 1) They're in RAM
> 2) They're still 8 bit.
> 
> Do anything in more than 8 bits SUCKS on the 6502!
> 
> They are surprisingly fast though given all the thrashing it has to
> do (8 bits, and only three registers).

It "does" 8-bit tasks very efficiently, and 8-bits is good enough for
 a lot of simple stuff, then and even today.  Literally millions of
 custom cores are executing 6502 code right now, hidden all over the
 world in toys, pacemakers, and many other devices.  It was the first
 assembly language that I learned, and is still my favorite, for a
 variety of reasons.  <<<< 6502 forever!!! >>>

Mike B.

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

#57220

On Wednesday, April 12, 2017 at 7:26:32 PM UTC+9, Albert van der Horst wrote:
> In article <86h91uui7d.fsf@molnjunk.nocrew.org>,
> Lars Brinkhoff  wrote:
> >Mark Wills wrote:
> >> Also, the 6502, whilst a very simple device and quite fast, has a
> >> crap instruction set and no registers.
> >
> >I haven't done any serious 6502 programming, so I wouldn't know.
> >Certainly, handling anything beyond 8 bits is going to be awkward, since
> >it's very insistent on being an 8-bitter.
> >
> >But at least the instruction set *encoding* is quite regular and
> >pleasant.  I wrote my own Forth assembler for it, and it turned out to
> >be very simple.

That has to be considered at least moderately serious programming.

> Indeed.
> There are misconceptions about the 6502.
> 6502 is the purest 8-bits processor yet very powerful. The
> implementation of FYSFORTH on the Apple II made it in an actually
> usable piece of equipment in the Fysisch Laboratorium of the Utrecht
> University.
> For the chip real estate it occupies it is one of the best.
> 
> If you know the chip you realize that it has 128 16 bit registers

Potentially 128 index register substitutes, which, because you don't have to load them into X (displacing whatever was in X) to use them as index registers, really are that useful.

As compared to the 6800 which also has potentially 128 index register substitutes in page zero, but requires precisely displacing whatever is in X to use them as such.

As accumulators or targets of 16 bit math, the zero page on the 6502 had pretty much the same set of disadvantages as the zero page on the 6800.

> on the zero page. If you don't appreciate that, you're in good company,
> Andrew Tannenbaum didn't realize that fact and dismissed the 6502
> as a potential target for a c-compiler.

Index registers are pretty important for high-level languages, which is why the 6502 was an early target for pascal virtual machines. 

But similar, but slightly slower VMs could have been built for the 6800.

C and VMs seem to be anathema, but there really isn't any reason the VM has to have in inner interpreter. Really, even on a large register CPU, the C run time essentially defines a VM that is imposed on the CPU and its register set.

It's a very flexible VM, but it is still a VM. That's perhaps the biggest reason that it's hard to get a classic Forth to co-exist with a C run-time. You have to understand both VMs and get them properly mapped to each other.

(Now, the 6809, which had both better support for the direct/zero page and memory indirection, did not have memory indirection on the direct/zero page. And that was kind of unfortunate, except I wonder how many more effective gates it would have required. I think it could have been shoe-horned into the index post-byte.

As it was, the 6809 only had, IIRC, about a thousand more gates than the 6502, and it could indirect through absolute variables or variables on the stack, so you didn't really feel the lack of indirection on the direct/zero page. Well, it would have made user page variables more convenient, but, again, with four actual indexable registers you still didn't feel it so much as on the 6800.)

> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.

Economic growth only has to be exponential when it is only the exponential growth that is accepted as meaningful. And that's why you picked that quote for a siggy, right?

> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57228

Joel Rees <joel.rees@gmail.com> writes:
>As it was, the 6809 only had, IIRC, about a thousand more gates than the 65=
>02

<https://en.wikipedia.org/wiki/Transistor_count>:

6502: 3510 transistors
6809: 9000 transistors

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#57231

On Thursday, April 13, 2017 at 6:09:48 AM UTC-5, Anton Ertl wrote:
> Joel Rees <joel.....@gmail.com> writes:
> >As it was, the 6809 only had, IIRC, about a thousand more gates than the 65=
> >02
> 
> <https://en.wikipedia.org/wiki/Transistor_count>:
> 
> 6502: 3510 transistors
> 6809: 9000 transistors
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2016: http://www.euroforth.org/ef16/

]> <https://en.wikipedia.org/wiki/Transistor_count>:
6809 and Z80 have very similar transistor counts.
IMHO Z80 makes very good use of memory bandwidth.
IMHO 6809 was/is the best of breed: most capable instruction set.
(and last to be introduced)

Which was fastest(at the same clock rate)?

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

#57234

On Thursday, 13 April 2017 14:33:28 UTC+1, jim.bra...@ieee.org  wrote:

> Which was fastest(at the same clock rate)?

IIRC the 6502 had the shortest instruction cycle times, but it typically
got less work done per instruction than a (for example) Z80.

I got the overall impression that the 6502 was faster though.

It's been a long time and I was just kid. ~13/14 years old. I was yet to
discover girls or Dire Straits. :-)

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

#57237

Mark Wills <markwills1970@gmail.com> wrote:
> On Thursday, 13 April 2017 14:33:28 UTC+1, jim.bra...@ieee.org  wrote:
> 
>> Which was fastest(at the same clock rate)?
> 
> IIRC the 6502 had the shortest instruction cycle times, but it typically
> got less work done per instruction than a (for example) Z80.
> 
> I got the overall impression that the 6502 was faster though.

6502 instructions took between 2-12 microseconds @ 1MHz.  Z80 was a
bit more complicated, but a Z80 machine cycle was 3 or 4 clocks, and
instructions took from 1-6 of theose cycles, so for a 2.5 MHz Z80
there was a speed advantage over the 1MHz 6502, especially given the
more powerful instructions, but it depended on what you were doing.
Later on, the Z80A was 4 Mhz and 6502s ran at 2 Mhz.

> It's been a long time and I was just kid. ~13/14 years old. I was yet to
> discover girls or Dire Straits. :-)

LOL!  :-)

Andrew.

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

#57244

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>6502 instructions took between 2-12 microseconds @ 1MHz.

They take 2-7 cycles, i.e., 2-7 microseconds @ 1MHz.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#57259

On Thursday, April 13, 2017 at 10:22:01 AM UTC-7, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> >6502 instructions took between 2-12 microseconds @ 1MHz.
> 
> They take 2-7 cycles, i.e., 2-7 microseconds @ 1MHz.

I noticed that too --- Andrew Haley was making stuff up again --- don't you Forth-200x committee members normally stick together though? Why did you correct him? 

Anyway, getting back to ISYS Forth and my ISYS-compatible cross-compiler, it used a split data-stack. We had two stacks, one for the high-byte and one for the low-byte. The high-byte stack was addressed with $40,X and the low-byte stack was addressed with $0,X --- so, only a single DEX was needed to make room on the data-stack for a new 16-bit cell, and only a single INX was needed to DROP a 16-bit cell. Very fast! Also, made the machine-code smaller.

By comparison, the Rockwell R65F11 Forth system had the high-byte and low-byte juxtaposed, so two DEX were needed to make room on the data-stack for a new 16-bit cell, and two INX wee needed to DROP a 16-bit cell. Very slow! 

One company that I worked for had tried the Rockwell Forth system in the past, but found it to be ponderously slow. After that experience, they gave up on Forth and switched to C. The Rockwell Forth used ITC which is extremely inefficient on the 6502. It is also unnecessary. A JSR instruction only takes 3 bytes, whereas an ITC link takes two, so ITC is only slightly smaller than STC. In ISYS Forth, as mentioned, DROP compiled into one byte. Also, ISYS Forth had jump-termination, meaning that a JSR followed by an RTS was converted into a JMP --- so 3 bytes in ISYS Forth compared to 4 bytes in an ITC system. Some code optimization done in ISYS Forth increased the size of the machine-code, but most of it decreased the size of the machine-code. In my cross-compiler, it was possible to turn on or off each kind of optimization as needed, so it was possible to optimize for speed or to optimize for size. Even when optimizing for size however, my code was about an order of magnitude faster than R65F11 code.

On a related note, I see that Stephen Pelc employs Randy Dumse of Rockwell R65F11 infamy:
http://www.mpeforth.com/sample-page/46-2/
I think this really shows the level of Forth skill that is accepted at MPE!

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

#57291

On Thursday, April 13, 2017 at 8:09:48 PM UTC+9, Anton Ertl wrote:
> Joel Rees  writes:
> >As it was, the 6809 only had, IIRC, about a thousand more gates than the 65=
> >02
> 
> <https://en.wikipedia.org/wiki/Transistor_count>:
> 
> 6502: 3510 transistors

My memory was more in the range of 6000+. Might be remembering a later part, however.

They do give a reference for that. The count is repeated in a number of places, but seems traceable to one book.

> 6809: 9000 transistors

My memory is in the range of 7000+.

I note that they don't show a reference, but that the number 9000 (too round, really) does show up around the web. So do other numbers. In particular, another wikipedia page

https://en.wikipedia.org/wiki/Microprocessor_chronology

indicates 11,000 transistors more than the 8086, which I am not going to believe. 

(Some point out that different sources will count the transistors differently, and one count may be gates, where another may be actual junctions, ...)

Do you have a reference, other than, say,

http://marc.info/?t=127528078100001&r=1&w=2

which has both counts, and mentions the question of how transistors are counted.

> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2016: http://www.euroforth.org/ef16/

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

#57240

On 4/13/2017 5:14 AM, Joel Rees wrote:
> On Wednesday, April 12, 2017 at 7:26:32 PM UTC+9, Albert van der
> Horst wrote:
>> In article <86h91uui7d.fsf@molnjunk.nocrew.org>, Lars Brinkhoff
>> wrote:
>>>
>>> But at least the instruction set *encoding* is quite regular and
>>> pleasant.  I wrote my own Forth assembler for it, and it turned
>>> out to be very simple.
>
> That has to be considered at least moderately serious programming.

What, writing an assembler?  We wrote an assembler for an IBM360 as a 
class assignment once.

-- 

Rick C

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

#57196

Mark Wills wrote:
> ...
> Also, the 6502, whilst a very simple device and quite fast, has a
> crap instruction set and no registers.

Keeping in mind it was intended to be a low-cost, bare-bones,
alternative to the 6800 aimed at microcontroller work, the limited
register set/size and missing instructions are understandable.
The failure to correct existing broken instructions wasn't.

>
> Yack. Just yack.

You can blame Wozniak and the hobbyists for the appearance of
the 6502 in systems for which it wasn't intended.  Tramiel and co.
weren't going to complain.  They were making buckets of money
riding the crest of a craze.

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

#57202

On Wednesday, April 12, 2017 at 5:43:35 PM UTC-7, HAA wrote:
> Mark Wills wrote:
> > ...
> > Also, the 6502, whilst a very simple device and quite fast, has a
> > crap instruction set and no registers.
> 
> Keeping in mind it was intended to be a low-cost, bare-bones,
> alternative to the 6800 aimed at microcontroller work, the limited
> register set/size and missing instructions are understandable.
> The failure to correct existing broken instructions wasn't.
> 
> >
> > Yack. Just yack.
> 
> You can blame Wozniak and the hobbyists for the appearance of
> the 6502 in systems for which it wasn't intended.  Tramiel and co.
> weren't going to complain.  They were making buckets of money
> riding the crest of a craze.

The 65c02 was a disappointment. It could have been so much better! If the JMP indirect instruction had used the Y register, the 65c02 would have been a very good processor for VMs. You could have 128 primitives each with a one-byte code. Your generated code would be quite compact. Most of the VM instructions would be one byte. Some of them would be two or three bytes because they have an operand. The NEXT routine would be very fast (note for Mark Wills: this NEXT would be about an order of magnitude faster than anything that could be done on the Z80).

In the 1980s, what people needed was a processor that could run a VM efficiently. Generating machine-code was not realistic (on any processor, including the Z80) because memory was too small. A VM however can be very efficient for memory, allowing people to write big programs. We could have had multiple VM systems --- Apple Pascal, Forth, Promal, etc. --- anybody could write a VM that was appropriate to whatever language they preferred. Eventually one of these languages would prove to be popular, then some chip-maker would build a processor that ran that VM as its machine-language to obtain a boost in speed of maybe a couple of orders of magnitude.

The 65c02 designers totally F'ed that up though --- they used the X register, not realizing that the X register is already used as the data-stack pointer in Forth --- they should have used the Y register that is typically a general-purpose register not dedicated to anything.

Also, they should have made the 65c02 address 128KB of memory. This would not have been difficult! All they needed was a 17-bit address-bus with the high-bit set when reading machine-code and unset when accessing data --- so, you have 64KB for machine-code and another 64KB for data (including the user's programs that are written in a VM of some kind).

These two features (the JMP indirect with Y rather than X and the 128KB memory) would have made the 65c02 far superior to the Z80 and pretty competitive with the i8088. CP/M and MS-DOS would not have gotten off the ground. Eventually we would have had a good OS available --- CP/M and MS-DOS were corporate products and were dull as dishwater --- the 65c02 programmers were a lot more intelligent and innovative by nature, so they would have done better. A Forth OS would have been pretty cool! The OS and language would both use the same command-line, so there would be no distinction between a "program" and a "function."

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web