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

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

Forth coding style vs "Algol et al" coding style

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

Contents

  Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-08 17:44 -0700
    Re: Forth coding style vs "Algol et al" coding style "WJ" <w_a_x_man@yahoo.com> - 2016-07-09 04:27 +0000
    Re: Forth coding style vs "Algol et al" coding style humptydumpty <ouatubi@gmail.com> - 2016-07-09 10:30 -0700
      Re: Forth coding style vs "Algol et al" coding style Julian Fondren <julian.fondren@gmail.com> - 2016-07-09 21:56 -0700
        Re: Forth coding style vs "Algol et al" coding style mhx@iae.nl - 2016-07-10 00:30 -0700
          Re: Forth coding style vs "Algol et al" coding style mhx@iae.nl - 2016-07-10 00:34 -0700
            Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-10 09:10 -0700
        Re: Forth coding style vs "Algol et al" coding style endlessboomcapitalism@gmail.com - 2016-07-12 18:55 -0700
    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-10 01:39 -0700
      Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-10 08:50 -0700
        Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-10 15:00 -0700
          Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-10 22:53 -0400
            Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 01:59 -0700
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 09:44 -0400
                Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:51 -0700
                  Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 15:26 -0400
                    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-12 15:18 -0700
                  Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-25 19:56 -0700
                    Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 23:13 -0400
                      Re: Forth coding style vs "Algol et al" coding style jim.brakefield@ieee.org - 2016-07-26 07:34 -0700
                        Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 11:23 -0400
                          Re: Forth coding style vs "Algol et al" coding style jim.brakefield@ieee.org - 2016-07-26 13:18 -0700
                            Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 18:14 -0400
                      Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:43 -0700
                        Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:24 -0400
                    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:46 -0700
                      Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:26 -0400
                    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:53 -0700
                      Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-27 08:32 -0700
                        Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-27 09:04 -0700
                          Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:05 -0700
                            Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-28 06:27 -0700
                              Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-29 03:01 -0700
                                Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-30 02:28 -0400
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 13:05 -0400
                Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:47 -0700
          Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 08:50 -0500
            Re: Forth coding style vs "Algol et al" coding style Michael Barry <barrym95838@yahoo.com> - 2016-07-11 08:23 -0700
              Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 11:48 -0500
                Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 12:16 -0500
                  Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:38 -0700
                    Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 13:32 -0500
                  Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 12:45 -0500
                    Re: Forth coding style vs "Algol et al" coding style Brad Eckert <hwfwguy@gmail.com> - 2016-07-11 11:49 -0700
                      Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-12 05:02 -0500
                Re: Forth coding style vs "Algol et al" coding style Michael Barry <barrym95838@yahoo.com> - 2016-07-11 14:22 -0700
                  Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 16:31 -0500
                  Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-12 15:31 -0400
                    Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:55 -0700
                      Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:48 -0400
                        Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-08-10 01:54 -0700
              Re: Forth coding style vs "Algol et al" coding style Howerd <howerdo@yahoo.co.uk> - 2016-07-11 11:58 -0700
            Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:59 -0700
              Re: Forth coding style vs "Algol et al" coding style Bernd Paysan <bernd.paysan@gmx.de> - 2016-07-26 00:40 +0000
                Re: Forth coding style vs "Algol et al" coding style "Elizabeth D. Rather" <erather@forth.com> - 2016-07-25 21:16 -1000
                Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-26 03:34 -0500
                Re: Forth coding style vs "Algol et al" coding style anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-26 16:51 +0000
                  Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 13:51 -0400
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:50 -0400
              Re: Forth coding style vs "Algol et al" coding style Brad Eckert <hwfwguy@gmail.com> - 2016-07-26 16:32 -0700
                Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:19 -0400
                  Re: Forth coding style vs "Algol et al" coding style "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:05 -1000
          Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:51 -0700
            Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-14 03:34 -0700
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:51 -0400
        Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 01:56 -0700
          Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-11 08:03 -0700

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

#49049

On Monday, 11 July 2016 18:16:17 UTC+1, Cecil - k5nwa  wrote:
> On 7/11/2016 11:48 AM, Andrew Haley wrote:
> > Michael Barry <barrym95838@yahoo.com> wrote:
> >
> >> I bought a book about 35 years ago that sampled several different 16-bit
> >> microprocessors, giving a large chapter to each one and providing
> >> architecture info and assembly code examples.  I think that it covered
> >> the 8086, 68000, 16000 (later renamed to 32000), 9900, and pdp-11.
> >
> > Interesting.  I was thinking it must have been the Osborne 16-bit
> > book, but that didn't cover the PDP-11.
> >
> >> I was reading the chapter on the pdp-11, and had reached the detailed
> >> description of the addressing modes.  My friend was sitting nearby, and
> >> suddenly asked if I was crying.  I actually was, a little bit, proving
> >> beyond a shadow of a doubt that I was a true nerd.
> >
> > Yep.  :-)
> >
> > Andrew.
> >
> I been playing with FPGAs to create, Forth processors, on my list of 
> items to create once I am more familiar with the VHDL software is to 
> create a PDP11 from scratch, the reason it's beautiful instruction set. 
> Funny thing is that with the FPGA one can create a PDP11 that is way 
> faster than the original models.
> 
> The TI 99XX family, and Nova mini will follow shortly after the PDP11 is 
> working. These processors have a very nice architecture, but I would 
> build the TI99xx without some of the silly limitations put on it with 
> the TI 9900 personal computers such as having 8 bit limited memory, and 
> of course a much faster CPU clock.
> 
> -- 
> Cecil - k5nwa

Don't look at the TI-99/4A - it has an awful architecture! The 9900 was put
in the 4A at the last minute. It should never have been in there. The mother
board is made for a processor with an 8 bit data bus, so data has to be pre-
assembled from two seperate 8 bit reads/writes and presented to the 9900 as
a complete 16-bit word. It's just awful!

The 9900 processor itself is fine, though it needs a 4 phase clock. Later
versions (9995) just had a single phase clock. The 9995 has an 8 bit databus
but is still more than twice as fast as a 9900 (and you can over clock them,
too - I've had them up past 12 megahertz). It has some extra instructions,
(signed divide and multiply) 256 bytes of internal ram, internal timers, and
instruction pre-fetch. If you're going to re-create any of them in VHDL, then
the 9995 is the one to go for, as it only needs 40 pins.

Actually, I have a VHDL implementation of it somewhere.

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

#49056

On 7/11/2016 12:38 PM, Mark Wills wrote:
> On Monday, 11 July 2016 18:16:17 UTC+1, Cecil - k5nwa  wrote:
>> On 7/11/2016 11:48 AM, Andrew Haley wrote:
>>> Michael Barry <barrym95838@yahoo.com> wrote:
>>>
>>>> I bought a book about 35 years ago that sampled several different 16-bit
>>>> microprocessors, giving a large chapter to each one and providing
>>>> architecture info and assembly code examples.  I think that it covered
>>>> the 8086, 68000, 16000 (later renamed to 32000), 9900, and pdp-11.
>>>
>>> Interesting.  I was thinking it must have been the Osborne 16-bit
>>> book, but that didn't cover the PDP-11.
>>>
>>>> I was reading the chapter on the pdp-11, and had reached the detailed
>>>> description of the addressing modes.  My friend was sitting nearby, and
>>>> suddenly asked if I was crying.  I actually was, a little bit, proving
>>>> beyond a shadow of a doubt that I was a true nerd.
>>>
>>> Yep.  :-)
>>>
>>> Andrew.
>>>
>> I been playing with FPGAs to create, Forth processors, on my list of
>> items to create once I am more familiar with the VHDL software is to
>> create a PDP11 from scratch, the reason it's beautiful instruction set.
>> Funny thing is that with the FPGA one can create a PDP11 that is way
>> faster than the original models.
>>
>> The TI 99XX family, and Nova mini will follow shortly after the PDP11 is
>> working. These processors have a very nice architecture, but I would
>> build the TI99xx without some of the silly limitations put on it with
>> the TI 9900 personal computers such as having 8 bit limited memory, and
>> of course a much faster CPU clock.
>>
>> --
>> Cecil - k5nwa
>
> Don't look at the TI-99/4A - it has an awful architecture! The 9900 was put
> in the 4A at the last minute. It should never have been in there. The mother
> board is made for a processor with an 8 bit data bus, so data has to be pre-
> assembled from two seperate 8 bit reads/writes and presented to the 9900 as
> a complete 16-bit word. It's just awful!
>
> The 9900 processor itself is fine, though it needs a 4 phase clock. Later
> versions (9995) just had a single phase clock. The 9995 has an 8 bit databus
> but is still more than twice as fast as a 9900 (and you can over clock them,
> too - I've had them up past 12 megahertz). It has some extra instructions,
> (signed divide and multiply) 256 bytes of internal ram, internal timers, and
> instruction pre-fetch. If you're going to re-create any of them in VHDL, then
> the 9995 is the one to go for, as it only needs 40 pins.
>
> Actually, I have a VHDL implementation of it somewhere.
>
I call those features silly, so I would not proceed to add them in. They 
crippled the performance of the machine, eventually I created my own 
board with 16 bit fast RAM, I liked that CPU. Like many things in 
electronics, performance and easy of use are only one small part of the 
equation, unfortunately marketing has a much bigger impact on which CPUs 
make it or not.

Back in the early 70s I designed my own CPU and built it, and one of the 
unusual feature of it was a register bank, dedicated high speed RAM that 
would be your register bank, you could switch the entire set for another 
in one instruction, fast for answering interrupts. One day I would like 
to go back to it and replicate it in an FPGA, it would be much faster, 
and a heck of a lot easier to make changes.

-- 
Cecil - k5nwa

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

#49050

Cecil Bayona <cbayona@cbayona.com> wrote:
>>
> I been playing with FPGAs to create, Forth processors, on my list of 
> items to create once I am more familiar with the VHDL software is to 
> create a PDP11 from scratch, the reason it's beautiful instruction set. 
> Funny thing is that with the FPGA one can create a PDP11 that is way 
> faster than the original models.

It's an interesting bit of history.  The DEC T11 had 13k transistors and
the 8086 had 29k; sigh.  History might have turned out very
differently.

Andrew.
 

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

#49057

On Monday, July 11, 2016 at 10:45:16 AM UTC-7, Andrew Haley wrote:
> 
> It's an interesting bit of history.  The DEC T11 had 13k transistors and
> the 8086 had 29k; sigh.  History might have turned out very
> differently.
> 
If Ken Olsen had entertained the idea that microcomputers might have a future, history could have turned out much differently. Of course, selling your customers much smaller and much cheaper computers was a mighty big leap of faith. Not such a leap these days since that kind of business model has been shown to work.

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

#49073

Brad Eckert <hwfwguy@gmail.com> wrote:
> On Monday, July 11, 2016 at 10:45:16 AM UTC-7, Andrew Haley wrote:
>> 
>> The DEC T11 had 13k transistors and the 8086 had 29k; sigh.
>> History might have turned out very differently.
>
> If Ken Olsen had entertained the idea that microcomputers might have
> a future, history could have turned out much differently. Of course,
> selling your customers much smaller and much cheaper computers was a
> mighty big leap of faith. Not such a leap these days since that kind
> of business model has been shown to work.

Indeed.

This reminds me that we often don't allow enough for the importance of
individual personalities in this industry.  It's so easy to focus on
the technology that I often fail to see how much is due to human
foibles and decisions made for short-term reasons.

Andrew.

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

#49062

On Monday, July 11, 2016 at 9:48:16 AM UTC-7, Andrew Haley wrote:
> ...
> Yep.  :-)
> 
> Andrew.

ISBN 0-672-21805-4

The Z8000 was in there too.  I still have the book at home somewhere.

Mike B.

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

#49063

On 7/11/2016 4:22 PM, Michael Barry wrote:
> ISBN 0-672-21805-4
Thanks, I put together boards to some of those processors, in the 70's 
and 80's.

Bought a used copy from Amazon, less than $5 including shipping.

-- 
Cecil - k5nwa

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

#49085

On 7/11/2016 5:22 PM, Michael Barry wrote:
> On Monday, July 11, 2016 at 9:48:16 AM UTC-7, Andrew Haley wrote:
>> ...
>> Yep.  :-)
>>
>> Andrew.
>
> ISBN 0-672-21805-4
>
> The Z8000 was in there too.  I still have the book at home somewhere.

The Z8000, 16 bit successor to the Z80?  I seem to recall that, like the 
Z80, this chip was designed and laid out by hand.  I believe the 
designer said he would never lay out another chip by hand.  I can't find 
the quote though.  Wikipedia says the Z8000 was *not* compatible with 
the Z80; was there another 16 bit Zxxx chip that was compatible?

-- 

Rick C

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

#49097

On Wednesday, July 13, 2016 at 7:31:26 AM UTC+12, rickman wrote:

> The Z8000, 16 bit successor to the Z80?

I had a look at the instruction set once. It had a peculiar segmentation scheme, where addresses were 32 bits but only the bottom 16 bits and some other 8-bit section near the top were used.

Imagine coming up with a segmentation scheme that was even worse than x86...

> I seem to recall that, like the Z80, this chip was designed and laid out by
> hand.

And pretty buggy to boot, from what I heard. Which limited its popularity somewhat...

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

#49509

On 7/12/2016 6:55 PM, lawrencedo99@gmail.com wrote:
> On Wednesday, July 13, 2016 at 7:31:26 AM UTC+12, rickman wrote:
>
>> The Z8000, 16 bit successor to the Z80?
>
> I had a look at the instruction set once. It had a peculiar segmentation scheme, where addresses were 32 bits but only the bottom 16 bits and some other 8-bit section near the top were used.

That makes sense.  If you aren't going to use the full 16 MB address 
space you can ignore some of the bits in the middle and create sections 
of of the address space in large hunks which you only use a small part 
of in *this* version of the chip.  They were trying to avoid the issue 
the PC had where physical memory from 640 kB to 1 MB was not used for RAM.


> Imagine coming up with a segmentation scheme that was even worse than x86...

I expect they were trying to plan ahead making a current system that 
wouldn't cripple future systems.  I seem to recall the default 
addressing used with the 68000 line was typically done that way too 
although this was chosen by the software people more than the chip design.


>> I seem to recall that, like the Z80, this chip was designed and laid out by
>> hand.
>
> And pretty buggy to boot, from what I heard. Which limited its popularity somewhat...
>


-- 

Rick C

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

#49920

On Tuesday, July 26, 2016 at 2:48:09 PM UTC+12, rickman wrote:
> On 7/12/2016 6:55 PM, Lawrence D’Oliveiro wrote:
>> On Wednesday, July 13, 2016 at 7:31:26 AM UTC+12, rickman wrote:
>>
>>> The Z8000, 16 bit successor to the Z80?
>>
>> I had a look at the instruction set once. It had a peculiar segmentation
>> scheme, where addresses were 32 bits but only the bottom 16 bits and some
>> other 8-bit section near the top were used.
> 
> That makes sense.

No it doesn’t. The Motorola 68000 did it by ignoring the top 8 bits. That way, you ended up with a linear 24-bit address space--much easier to work with.

For example, the Macintosh platform was able to go from 16-bit to 32-bit in the late 1980s with very little drama. Compare the ructions the Windows/x86 world had to go through, nearly a decade later.

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

#49058

Hi Mike,

Thank you for making me laugh :-)

I haven't had laugh like that for ages, apart, obviously, from a disbelieving, despairing kind of laugh that any sensitive soul would get from some of the posts on clf...

Best regards,
Howerd
 

On Monday, 11 July 2016 16:23:24 UTC+1, Michael Barry  wrote:
> On Monday, July 11, 2016 at 6:50:54 AM UTC-7, Andrew Haley wrote:
> > ...  Mind you, if we're
> > going to look at an elegant 1970s minicomputer architecture, I'm
> > pretty sure that the PDP-11 would win!
> > 
> > Andrew.
> 
> I bought a book about 35 years ago that sampled several different 16-bit
>  microprocessors, giving a large chapter to each one and providing
>  architecture info and assembly code examples.  I think that it covered
>  the 8086, 68000, 16000 (later renamed to 32000), 9900, and pdp-11.
> 
> I was reading the chapter on the pdp-11, and had reached the detailed
>  description of the addressing modes.  My friend was sitting nearby, and
>  suddenly asked if I was crying.  I actually was, a little bit, proving
>  beyond a shadow of a doubt that I was a true nerd.
> 
> Mike B.

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

#49098

On Tuesday, July 12, 2016 at 1:50:54 AM UTC+12, Andrew Haley wrote:
> I'll passon the 68k, but the 9900 was nice enough.  Mind you, if we're
> going to look at an elegant 1970s minicomputer architecture, I'm
> pretty sure that the PDP-11 would win!

I think the 680x0 family were definitely inspired by the PDP-11.

One nice thing about the original 68000: even thought it was classed as a “16-bit” chip, it was very clearly a cut-down 32-bit design. Unfortunately, this hurt its performance in the short term, compared to Intel x86 and others.

But in the long term, it made it very easy for software to move to full 32-bit processors like the 68020 and later. In the Apple Mac world this happened with very little pain, from the late 1980s onwards. Compare the massive ructions in the Windows world nearly a decade later, with the coming of Windows 95 and the move to “Win32”.

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

#49507

Am Tue, 12 Jul 2016 15:59:11 -0700 schrieb lawrencedo99:
> I think the 680x0 family were definitely inspired by the PDP-11.

Indeed.

> One nice thing about the original 68000: even thought it was classed as
> a “16-bit” chip, it was very clearly a cut-down 32-bit design.
> Unfortunately, this hurt its performance in the short term, compared to
> Intel x86 and others.

No, performance wasn't the problem.  According to this FAQ, the 8MHz 68k 
had 2100 dhrystones (other reports show lower scores; this, after all, is 
also a compiler issue), while an 8088 had just ~300, and a 10MHz 286 had 
1889, still less than the 68k at 8MHz.

http://www.faqs.org/faqs/motorola/68k-chips-faq/

The 68k had more room for compilers to improve, with 16 registers, 
register allocation could actually utilize the registers, while the 8086 
hand only 8 special purpose registers.

The primary reason these CISC processors weren't very fast was that they 
all used microcode, and couldn't do single cycle instructions (the 68k 
needed 4 cycles for simple instructions).  The early RISC with similar 
die size ran a lot faster.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#49521

On 7/25/16 2:40 PM, Bernd Paysan wrote:
> Am Tue, 12 Jul 2016 15:59:11 -0700 schrieb lawrencedo99:
>> I think the 680x0 family were definitely inspired by the PDP-11.
>
> Indeed.
>
>> One nice thing about the original 68000: even thought it was classed as
>> a “16-bit” chip, it was very clearly a cut-down 32-bit design.
>> Unfortunately, this hurt its performance in the short term, compared to
>> Intel x86 and others.

I never actually saw any 16-bit Forths on the 68K. FORTH, Inc. addressed 
it as a 32-bit system from the start.

> No, performance wasn't the problem.  According to this FAQ, the 8MHz 68k
> had 2100 dhrystones (other reports show lower scores; this, after all, is
> also a compiler issue), while an 8088 had just ~300, and a 10MHz 286 had
> 1889, still less than the 68k at 8MHz.
>
> http://www.faqs.org/faqs/motorola/68k-chips-faq/
>
> The 68k had more room for compilers to improve, with 16 registers,
> register allocation could actually utilize the registers, while the 8086
> hand only 8 special purpose registers.

Yes, it was quite liberating.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#49524

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Am Tue, 12 Jul 2016 15:59:11 -0700 schrieb lawrencedo99:
>> I think the 680x0 family were definitely inspired by the PDP-11.
> 
> Indeed.
> 
>> One nice thing about the original 68000: even thought it was classed as
>> a ?16-bit? chip, it was very clearly a cut-down 32-bit design.
>> Unfortunately, this hurt its performance in the short term, compared to
>> Intel x86 and others.
> 
> No, performance wasn't the problem.  According to this FAQ, the 8MHz
> 68k had 2100 dhrystones (other reports show lower scores; this,
> after all, is also a compiler issue), while an 8088 had just ~300,
> and a 10MHz 286 had 1889, still less than the 68k at 8MHz.

That must be wrong.  The original 68000 was not great; it certainly
was not hugely faster than the 8086 of the same time.  If you look at
the instruction cycle times they're not hugely different, so any large
difference is not due to the processor.

Here's Dhrystone 1.0 info from 1984:

http://ibm-1401.info/Dhrystone.html

 * IBM PC/XT	8088-4.77Mhz	COHERENT 2.3.43	MarkWilliams cc  296	 317
 * Cosmos	68000-8Mhz	UniSoft		cc		 305	 322
 * IBM PC/XT	8088-4.77Mhz	Venix/86 2.0	cc		 297	 324

This is more like it.  Much of Dhrystone is trivially optimizable.

Andrew.

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

#49543

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Tue, 12 Jul 2016 15:59:11 -0700 schrieb lawrencedo99:
>> I think the 680x0 family were definitely inspired by the PDP-11.
>
>Indeed.

The PDP-11 certainly was very influential, but the 68000 was not
particularly strongly inspired by it.  In particular, the 68000 does
not have general-purpose registers, which was one of the major changes
of the PDP-11 compared to the PDP-8 (and the PDP-8 offspring and
competing design which later became the DG Nova); instead the 68000
has data and address registers, i.e., accumulators and index
registers; so it's a generalized accumulator architecture rather than
a register architecture.  Maybe the CDC-6600 (also a generalized
register architecture) had more of an influence on the 68000
architecture than the PDP-11.

>> One nice thing about the original 68000: even thought it was classed as
>> a "16-bit" chip, it was very clearly a cut-down 32-bit design.
>> Unfortunately, this hurt its performance in the short term, compared to
>> Intel x86 and others.
>
>No, performance wasn't the problem.  According to this FAQ, the 8MHz 68k 
>had 2100 dhrystones (other reports show lower scores; this, after all, is 
>also a compiler issue), while an 8088 had just ~300, and a 10MHz 286 had 
>1889, still less than the 68k at 8MHz.
>
>http://www.faqs.org/faqs/motorola/68k-chips-faq/

The benchmark results I saw at the time mostly reported the 80286 to
be faster then the 68000.  Looking at the cycle counts (e.g.,
<http://zsmith.co/intel_a.html#add>,
<https://wiki.neogeodev.org/index.php?title=68k_instructions_timings>:

(d)reg += (d)reg is 2 cycles on the 80286, 8 cycles on the 68000
(d)reg += mem is 7 cycles on the 80286, 8(BW)-14(L) cycles on the 68000
mem += (d)reg is 7 cycles on the 80286, 12(BW)-20(L) cycles on the 68000

Sure, you can save some instructions and some memory accesses on the
68000 by keeping things in registers or by using autoincrement, but
that will usually not make up for such big differences in cycle
counts.

>The primary reason these CISC processors weren't very fast was that they 
>all used microcode, and couldn't do single cycle instructions (the 68k 
>needed 4 cycles for simple instructions).  The early RISC with similar 
>die size ran a lot faster.

Apart from the IBM 801 (1980, but probably not a single chip, and not
a product anyway), they all came quite a bit later, 1985 and later.
The 386 (1985) had similar cycle counts as the 286; single-cycle
instructions were achieved by Intel with the 486 (1989) and Motorola
with the 68040 (1990).

Maybe, if the RISC design principles had been developed and
disseminated already in 1976, the 68000 design team (which did not go
for software compatibility, unlike Intel) might have designed
something more RISC-like (although probably with 16-bit instructions);
the 68000 had a similar number of transistors (40000 according to
<https://en.wikipedia.org/wiki/Motorola_68000#History>) as the ARM1
(25000), was manufactured in a similar-sized process (3.5um vs. 3um)
and had a similar area (44mm^2 vs. 50mm^2), so it should have been
possible.  They might also have been faster in completing their
design.

- 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]

#49544

On 7/26/2016 12:51 PM, Anton Ertl wrote:
>
> Maybe, if the RISC design principles had been developed and
> disseminated already in 1976, the 68000 design team (which did not go
> for software compatibility, unlike Intel) might have designed
> something more RISC-like (although probably with 16-bit instructions);
> the 68000 had a similar number of transistors (40000 according to
> <https://en.wikipedia.org/wiki/Motorola_68000#History>) as the ARM1
> (25000), was manufactured in a similar-sized process (3.5um vs. 3um)
> and had a similar area (44mm^2 vs. 50mm^2), so it should have been
> possible.  They might also have been faster in completing their
> design.

One should never discount time to market with nearly any product.

-- 

Rick C

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

#49510

On 7/12/2016 6:59 PM, lawrencedo99@gmail.com wrote:
> On Tuesday, July 12, 2016 at 1:50:54 AM UTC+12, Andrew Haley wrote:
>> I'll passon the 68k, but the 9900 was nice enough.  Mind you, if we're
>> going to look at an elegant 1970s minicomputer architecture, I'm
>> pretty sure that the PDP-11 would win!
>
> I think the 680x0 family were definitely inspired by the PDP-11.
>
> One nice thing about the original 68000: even thought it was classed as a “16-bit” chip, it was very clearly a cut-down 32-bit design. Unfortunately, this hurt its performance in the short term, compared to Intel x86 and others.
>
> But in the long term, it made it very easy for software to move to full 32-bit processors like the 68020 and later. In the Apple Mac world this happened with very little pain, from the late 1980s onwards. Compare the massive ructions in the Windows world nearly a decade later, with the coming of Windows 95 and the move to “Win32”.

It made it a PITA to design at that time too.  I read the original 
microcode block was larger in length than the allocated die size.  They 
had to use picocoding to make it fit.  Yup, they had microcoded 
microcode.  Maybe someone was inspired by Forth.

-- 

Rick C

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

#49549

On Tuesday, July 12, 2016 at 3:59:13 PM UTC-7, lawren...@gmail.com wrote:
> On Tuesday, July 12, 2016 at 1:50:54 AM UTC+12, Andrew Haley wrote:
> > I'll passon the 68k, but the 9900 was nice enough.  Mind you, if we're
> > going to look at an elegant 1970s minicomputer architecture, I'm
> > pretty sure that the PDP-11 would win!
> 
> I think the 680x0 family were definitely inspired by the PDP-11.
> 
> One nice thing about the original 68000: even thought it was classed as a “16-bit” chip, it was very clearly a cut-down 32-bit design. Unfortunately, this hurt its performance in the short term, compared to Intel x86 and others.
> 

Intel can probably attribute the success of the x86 to its lawyers. They knew how far they could push the envelope with regards to bundling. You want to build a PC? Here's a sweet deal on DRAM if you design in the x86. BTW, bundling is how they later killed chipset vendor VLSI. VLSI had the cost advantage in motherboard chipsets, but Intel put together bundling deals that took that away. The early days of Wintel really was the wild, wild west.

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

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

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

csiph-web