Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48971 > unrolled thread
| Started by | foxaudioresearch@gmail.com |
|---|---|
| First post | 2016-07-08 17:44 -0700 |
| Last post | 2016-07-11 08:03 -0700 |
| Articles | 20 on this page of 74 — 19 participants |
Back to article view | Back to comp.lang.forth
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 rickman <gnuarm@gmail.com> - 2016-08-21 19:32 -0400
Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-08-28 22:55 -0700
Re: Forth coding style vs "Algol et al" coding style hughaguilar96@gmail.com - 2016-08-29 00:34 -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 Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-21 23:04 +0000
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 Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-21 23:13 +0000
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 Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-21 23:38 +0000
Re: Forth coding style vs "Algol et al" coding style anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-22 12:51 +0000
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 →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-11 10:38 -0700 |
| Message-ID | <b8fbea90-24bf-4d1d-bc9c-3428c71e0402@googlegroups.com> |
| In reply to | #49048 |
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]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-07-11 13:32 -0500 |
| Message-ID | <nm0onc$saq$1@dont-email.me> |
| In reply to | #49049 |
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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-11 12:45 -0500 |
| Message-ID | <K8ydnXLapLW7Rh7KnZ2dnUU7-LudnZ2d@supernews.com> |
| In reply to | #49048 |
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]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-11 11:49 -0700 |
| Message-ID | <61e64b3b-af8c-44d3-8132-ac0023c661c3@googlegroups.com> |
| In reply to | #49050 |
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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-12 05:02 -0500 |
| Message-ID | <c9qdnQKsi7rSXRnKnZ2dnUU7-R2dnZ2d@supernews.com> |
| In reply to | #49057 |
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]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2016-07-11 14:22 -0700 |
| Message-ID | <740c6b01-c87a-4143-a062-6dbf5eeca05a@googlegroups.com> |
| In reply to | #49045 |
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]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-07-11 16:31 -0500 |
| Message-ID | <98036eb3-000b-e28a-90ca-283122fe656a@cbayona.com> |
| In reply to | #49062 |
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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-12 15:31 -0400 |
| Message-ID | <nm3gic$pbe$1@dont-email.me> |
| In reply to | #49062 |
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]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-07-12 15:55 -0700 |
| Message-ID | <552de51e-52f1-4470-b079-725099716f33@googlegroups.com> |
| In reply to | #49085 |
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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-25 22:48 -0400 |
| Message-ID | <nn6j17$p19$1@dont-email.me> |
| In reply to | #49097 |
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]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-10 01:54 -0700 |
| Message-ID | <9f2ac50f-25e5-4e10-abfa-6a1b599d9e24@googlegroups.com> |
| In reply to | #49509 |
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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-08-21 19:32 -0400 |
| Message-ID | <npddn3$6qd$1@dont-email.me> |
| In reply to | #49920 |
On 8/10/2016 4:54 AM, lawrencedo99@gmail.com wrote: > 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. You seem to be mixing apples and oranges. Don't blame Zilog for the problems with the Intel processors. The Zilog method was perfectly sane. In fact, the 68000 family had some issues with the limited 24 bit address space. When later models came out with full 32 bit address pins, there was code that was not compatible.. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-28 22:55 -0700 |
| Message-ID | <568c56ce-ee41-4fa9-a703-e272257ea466@googlegroups.com> |
| In reply to | #50369 |
On Monday, August 22, 2016 at 11:32:52 AM UTC+12, rickman wrote: > In fact, the 68000 family had some issues with the limited 24 bit > address space. When later models came out with full 32 bit address > pins, there was code that was not compatible.. The fact remains, the incompatibilities were far less of a problem than with x86, where going to 32-bit required major changes and took many more years.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-29 00:34 -0700 |
| Message-ID | <102e7771-a266-413d-bdea-13b6d62b3609@googlegroups.com> |
| In reply to | #50538 |
On Sunday, August 28, 2016 at 10:55:29 PM UTC-7, lawren...@gmail.com wrote: > On Monday, August 22, 2016 at 11:32:52 AM UTC+12, rickman wrote: > > In fact, the 68000 family had some issues with the limited 24 bit > > address space. When later models came out with full 32 bit address > > pins, there was code that was not compatible.. > > The fact remains, the incompatibilities were far less of a problem than with x86, where going to 32-bit required major changes and took many more years. I don't recall any major changes. UR/Forth had something similar to the Small memory-model and all my programs were small enough to work in this --- if I had been using ES explicitly to access more than 64KB then I would have had difficulty upgrading to 32-bit --- I didn't though, even for large programs. I remember when I got into Forth in 1984 that the need to eventually make code portable to 32-bit systems was already obvious (I knew a college student who was programming in Forth, and he pointed out to me that 32-bit processors existed and would eventually be affordable even by people like me). I started using W has a constant to be the size of a "word" (nowadays called "cell"). On 16-bit UR/Forth my W was 2, and when I eventually upgraded to 32-bit UR/Forth then W became 4 --- all my software upgraded without any difficulty (it took minutes, not years) --- afaik, all of the Forth-83 programmers had a constant for the word size, although they didn't all use the name W (one of the many failings of Forth-83 was not giving this constant a standard name; the need should have been obvious in 1983, as the MC68000 was already available). Who wrote the Forth-83 standard? That was before my time, as I didn't get into Forth until 1984. I assume that Forth-83 was yet another Forth Inc. screw-up. Who else is there to blame for the many failings of Forth-83 and Forth-79? FIGforth had problems too, but FIGforth was an implementation; it never tried to be a standard --- afaik, FIGforth was just a pirated version of MicroForth from Forth Inc. that had been ported from the PDP-11 over to the 6502 (later to the MC6809, Z80, etc.) and it represented Forth state-of-the art circa about 1977. My understanding was that Charles Moore was okay with letting FIG publish FIGforth because MicroForth was already obsolete anyway, but he told FIG to not compete against his more modern work, which is why there was never an upgrade to FIGforth. At the time that I got into Forth, FIGforth was obsolete and nobody used it, but FIG was still important in the Forth world because they published the "Forth Dimensions" magazine. There was good information in that magazine in the old days, but over time their quality level went down --- by the time that the magazine died in the early 1990s, nobody was reading it anyway because it wasn't very good anymore --- Forth was pretty much dead in the early 1990s, and then ANS-Forth came out in 1994 which really nailed the coffin lid shut permanently. Forth was really a good language --- there was just a lack of leadership after Charles Moore got kicked out of Forth Inc., and so Forth died on the vine --- a lack of leadership continues to be the problem today.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2016-07-11 11:58 -0700 |
| Message-ID | <def74942-9a58-4402-b887-801cdc981fcf@googlegroups.com> |
| In reply to | #49043 |
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]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-07-12 15:59 -0700 |
| Message-ID | <81c72add-bac3-4c44-a873-0d7d71d9d80e@googlegroups.com> |
| In reply to | #49041 |
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]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-07-26 00:40 +0000 |
| Message-ID | <nn6bhm$pju$1@dont-email.me> |
| In reply to | #49098 |
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]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-25 21:16 -1000 |
| Message-ID | <Fcqdnarvv-7XkwrKnZ2dnUU7-d2dnZ2d@supernews.com> |
| In reply to | #49507 |
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]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-08-21 23:04 +0000 |
| Message-ID | <npdc14$vqt$3@dont-email.me> |
| In reply to | #49521 |
Am Mon, 25 Jul 2016 21:16:25 -1000 schrieb Elizabeth D. Rather: > I never actually saw any 16-bit Forths on the 68K. FORTH, Inc. addressed > it as a 32-bit system from the start. VolksForth was 16 bit on the 68k. The VolksForth authors quickly started a 32 bit version, and handed that over to me, where it became bigForth. It did make much more sense to run 32 bit on the 68k, and for speed invest some effort in a native code compiler. The 8086 Forths were using threaded code for much longer than the 68k Forths. -- 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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-26 03:34 -0500 |
| Message-ID | <rpGdnSdiUtMOvQrKnZ2dnUU78T_NnZ2d@supernews.com> |
| In reply to | #49507 |
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]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web