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 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 4 of 4 — ← Prev page 1 2 3 [4]

#50367

Am Tue, 26 Jul 2016 03:34:27 -0500 schrieb Andrew Haley:

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

Well, maybe due to the compiler...

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

On the other hand, bigForth's benchmarks were 8 times faster on a 
386@33MHz than on the Atari ST with 8MHz; that was expected with the 2-
cycles-per-instruction on the 386, and four times the clock.  The 386 had 
~9000 Dhrystones at that frequency.  Can't be less than 1000 Dhrystones 
unless the compiler screwed up.

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

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

#50370

Am Tue, 26 Jul 2016 13:51:43 -0400 schrieb rickman:

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

Yes, Roger/Sophie Wilson and Steve Furber took two years to get ARM1 into 
production; I don't know how big the entire team actually was, but AFAIK 
pretty small.  The 68k also took two years from project start to first 
samples, with a larger team, 42 people in the design team alone.

http://archive.computerhistory.org/resources/access/
text/2012/04/102658164-05-01-acc.pdf

If time to market matters and you have the concept of RISC and CISC 
available to choose from (which wasn't quite the case in 1979, though 
some guys at IBM already did experiment in that direction), go RISC, and 
get a faster processor in less time.

But Motorola showed that when they design RISCs their way, they aren't 
good designs.  They ended up using an architecture from IBM instead...

The good thing about a CISC CPU and design-by-committee is that the 
committee works on the CISC parts, which are implemented in microcode.  
The actual inner working is not done by the committee.  If you let them 
design a RISC, it ends up as complex as the CISC, but you can't implement 
the complexity in microcode.  All the WIBNI features that can easily be 
shoved into one or the other corner of the microcode ROM now need full 
attention.

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

#50405

Bernd Paysan <bernd.paysan@gmx.de> writes:
>But Motorola showed that when they design RISCs their way, they aren't 
>good designs.  They ended up using an architecture from IBM instead...

Having used 88k-based machines, I found the architecture fine.  The
88100 implementation did not quite reach the speeds of contemporary
MIPSes, but was not far behind.  It did have a problem with market
acceptance, as it came out 2 years after MIPS, HPPA, and SPARC; Data
General was probably the biggest customer.  There were supposedly
plans by Apollo, NeXT, and Apple, to switch to the 88000, but Apollo
rolled their own architecture (somewhere I read that they did it
because the 88100 was late), and got bought by HP, who had their own
RISC architecture (HPPA); NeXT was bought by Apple, and Apple entered
the AIM alliance with IBM and Motorola.

They did have a problem with their next implementation, the 88110,
which was late and not particularly fast compared to the competition
(introduced at 50MHz in 1992; in the same year the Alpha 21064 was
introduced with 150-200MHz).  They also had similar problems with the
68060 (introduced at 50MHz in 1994).

So given the low market share of the 88k, and the uncompetetive
implementation, it's pretty logical that, when Motorola entered the
AIM alliance, they abandoned the 88k architecture for the PowerPC
architecture, for which a relatively fast single-chip implementation
already existed.  They did contribute the 88110 bus to the PowerPC,
though.

>The good thing about a CISC CPU and design-by-committee is that the 
>committee works on the CISC parts, which are implemented in microcode.  
>The actual inner working is not done by the committee.  If you let them 
>design a RISC, it ends up as complex as the CISC, but you can't implement 
>the complexity in microcode.

Did not help the 68060, which was two years later and not any faster
than the 88110.

>All the WIBNI features that can easily be 
>shoved into one or the other corner of the microcode ROM now need full 
>attention.

An example of the approach you seem may be advocating is the
Williamette/Northwood (Pentium 4): It had a very fast integer core
that could do relatively little; e.g., it could not shift or multiply,
and it shipped data over to the FPU for these WIBNI features.

However, it seems that Intel is slowly making the neglected features
fast; e.g,., in the Wolfdale (45nm Core 2 Duo), a cache-line crossing
load takes 13 cycles, and a page-crossing memory load takes 169 cycles
<2015Mar31.135537@mips.complang.tuwien.ac.at>, while these take 1.98
and 31 cycles, respectively, on an Ivy Bridge.  It seems to me that
the performance gains that we have seen from Intel in recent years
are, for a good part due to improving the performance of such
neglected features.

But then, unaligned access is not WIBNI: Stephen Pelc himself sees a
need for that, so, following from the definition of "WIBNI", it is not
WIBNI.

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

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

#49562

On 7/26/2016 7:32 PM, Brad Eckert wrote:
> 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.

Uh, what alternatives did anyone have to the x86?  I think Intel can 
thank IBM for making them successful.  That and knowing how to make 
chips.  You have to give Intel credit for doing some things right.

-- 

Rick C

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

#49581

On 7/27/16 4:19 AM, rickman wrote:
> On 7/26/2016 7:32 PM, Brad Eckert wrote:
>> 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.
>
> Uh, what alternatives did anyone have to the x86?  I think Intel can
> thank IBM for making them successful.  That and knowing how to make
> chips.  You have to give Intel credit for doing some things right.

The x86 took over the PC world for sure, but for various control 
applications the whole range of processors from the low-power 1804 to 
8051's, the 68xx family, and the 68000 family was thriving.

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]

#49095

On Monday, July 11, 2016 at 10:00:43 AM UTC+12, Mark Wills wrote:

> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> over the years. The 68K comes a close second for me :-)

Ever programmed a VAX? Polynomial evaluation in a single instruction...

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

#49158

On Tuesday, 12 July 2016 23:51:20 UTC+1, lawren...@gmail.com  wrote:
> On Monday, July 11, 2016 at 10:00:43 AM UTC+12, Mark Wills wrote:
> 
> > Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> > over the years. The 68K comes a close second for me :-)
> 
> Ever programmed a VAX? Polynomial evaluation in a single instruction...

Yes, but only in "high-level" languages - C specifically.

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

#49511

On 7/14/2016 6:34 AM, Mark Wills wrote:
> On Tuesday, 12 July 2016 23:51:20 UTC+1, lawren...@gmail.com  wrote:
>> On Monday, July 11, 2016 at 10:00:43 AM UTC+12, Mark Wills wrote:
>>
>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
>>> over the years. The 68K comes a close second for me :-)
>>
>> Ever programmed a VAX? Polynomial evaluation in a single instruction...
>
> Yes, but only in "high-level" languages - C specifically.

How does a HLL impact the ability to use assembly code?

-- 

Rick C

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

#49033

On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> Sure have Mark. It's very nice.  
> 
> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> 
> The cycle count looks like it will be faster.
> 
> 
> Boy I like that TmS9900 instruction set better than x86.
> 
> Just needs a stack pointer or 2 in Hardware.
> 
> B

If you need any pointers/help with the weirdness of the 4A architecture just
drop me an email. It's a bizarre machine. Also, the full source code to 
TurboForth is on the website (go to the resources section) which might contain
some useful stuff for you. I also have lots of TI documentation in PDF format
should you need anything.

I'll be very interested indeed to see your cross compiler and Camel Forth
on the TI99. So, you're using your cross compiler to produce Camel Forth?

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

#49042

On Monday, July 11, 2016 at 4:56:37 AM UTC-4, Mark Wills wrote:
> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> > Sure have Mark. It's very nice.  
> > 
> > I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> > 
> > The cycle count looks like it will be faster.
> > 
> > 
> > Boy I like that TmS9900 instruction set better than x86.
> > 
> > Just needs a stack pointer or 2 in Hardware.
> > 
> > B
> 
> If you need any pointers/help with the weirdness of the 4A architecture just
> drop me an email. It's a bizarre machine. Also, the full source code to 
> TurboForth is on the website (go to the resources section) which might contain
> some useful stuff for you. I also have lots of TI documentation in PDF format
> should you need anything.
> 
> I'll be very interested indeed to see your cross compiler and Camel Forth
> on the TI99. So, you're using your cross compiler to produce Camel Forth?

Yes, Once I got the cross-compiler running to produce a DOS Forth, I thought it would be fun to cross compile to 9900. (bucket list thing) The assembler is making images that run on a TI-99 emulator, so the rest is just making all the primitives work.

BF

[toc] | [prev] | [standalone]

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

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

csiph-web