Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #47022 > unrolled thread
| Started by | murphy.darin@gmail.com |
|---|---|
| First post | 2016-05-11 13:54 -0700 |
| Last post | 2016-05-16 05:35 +0000 |
| Articles | 20 on this page of 91 — 18 participants |
Back to article view | Back to comp.lang.forth
Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 13:54 -0700
Re: Looking for some help with this gforth program. Thanks! all2001@spambog.com (Wolfgang Allinger) - 2016-05-11 17:59 -0300
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 19:16 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 19:40 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-11 23:22 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 00:01 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-12 00:08 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 12:09 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 20:48 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 18:04 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 21:21 -0400
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 20:27 -0500
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-12 18:46 -0700
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 23:28 -0500
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 00:52 -0700
Re: Looking for some help with this gforth program. Thanks! Pablo Hugo Reda <pabloreda@gmail.com> - 2016-05-13 04:07 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-14 00:42 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:05 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 00:10 -0400
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-15 10:34 +0000
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 09:43 -0400
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 12:21 +0000
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-16 07:38 -0700
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 14:56 +0000
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-16 12:07 -0400
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 09:18 -0700
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 13:19 -0500
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 12:39 +0000
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-17 10:34 -0500
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 15:54 +0000
Re: Looking for some help with this gforth program. Thanks! mhx@iae.nl - 2016-05-17 12:44 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:03 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 21:56 -0400
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-15 19:02 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 20:03 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-16 02:13 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 00:37 -0700
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 13:41 +0000
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-16 21:42 +0000
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-16 16:23 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 16:41 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 20:32 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 20:47 -0700
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 06:32 +0000
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 07:56 -0700
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-17 23:05 +0000
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 21:16 -0700
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-06-04 22:44 +0000
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 13:42 +0000
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-17 22:31 +0000
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-18 16:43 +0000
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 10:38 -0500
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 10:10 -0700
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-16 12:29 -0500
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-16 12:34 -0500
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 13:27 -0500
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 16:11 -0700
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 04:31 -0500
Re: Looking for some help with this gforth program. Thanks! Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-16 18:46 +0000
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:07 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:20 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-14 01:23 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 00:13 -0400
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-14 21:55 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-11 17:08 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 17:40 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 18:54 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-13 06:55 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 11:07 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-13 20:42 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 20:57 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-14 05:54 -0400
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-14 15:20 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-15 05:45 -0400
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:21 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:39 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 20:45 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 23:05 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 23:15 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 22:34 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 23:11 -0700
Re: Looking for some help with this gforth program. Thanks! november.nihal@gmail.com - 2016-05-11 19:00 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 19:14 -0700
Re: Looking for some help with this gforth program. Thanks! humptydumpty <ouatubi@gmail.com> - 2016-05-12 01:48 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-12 07:43 -0400
Re: Looking for some help with this gforth program. Thanks! humptydumpty <ouatubi@gmail.com> - 2016-05-12 10:21 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 12:11 -0700
Re: Looking for some help with this gforth program. Thanks! "Ala'a" <amalawi@gmail.com> - 2016-05-12 14:34 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 16:20 -0700
Re: Looking for some help with this gforth program. Thanks! Marcos Cruz <use_the_contact_page@programandala.net> - 2016-05-14 12:27 +0000
Re: Looking for some help with this gforth program. Thanks! "WJ" <w_a_x_man@yahoo.com> - 2016-05-16 05:35 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-15 09:43 -0400 |
| Message-ID | <nh9u7g$cl1$1@dont-email.me> |
| In reply to | #47139 |
On 5/15/2016 6:34 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> I have no idea why anyone would say a conventional processor designed to >> run C programs efficiently would not be suitable for running Forth. I >> don't know of any reason why the two would be mutually exclusive. > > Right. Forth is a language that was designed to be close to the > machine, so it's unsurprising that it can be implemented efficiently > on existing machines. It takes a more effort (and complexity) to > implement it very efficiently than a Forth implementation on a Forth > processor, though. But if you are prepared to sacrifice some run-time > efficiency for simplicity, compilation can be very simple: see machine > Forth for the 386. I'm a bit surprised to hear anyone say implementing Forth on an x86 is anything but easy... well as easy as it would be on any CPU including stack machines. The primary difference between a stack machine and the x86 is the lack of flexibility in the stack machine. An x86 processor can do all the stack manipulations the stack machine can do as well as any manner of optimizations made possible by the register set and hugely flexible addressing modes. When I designed my stack machine I gave it some features that were actually more efficient than the Forth virtual machine such as use of the return stack to hold and manipulate addresses separate from data. So maybe it is the Forth VM itself that limits efficiency. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-05-16 12:21 +0000 |
| Message-ID | <2016May16.142145@mips.complang.tuwien.ac.at> |
| In reply to | #47144 |
rickman <gnuarm@gmail.com> writes:
>I'm a bit surprised to hear anyone say implementing Forth on an x86 is
>anything but easy... well as easy as it would be on any CPU including
>stack machines. The primary difference between a stack machine and the
>x86 is the lack of flexibility in the stack machine. An x86 processor
>can do all the stack manipulations the stack machine can do as well as
>any manner of optimizations made possible by the register set and hugely
>flexible addressing modes.
If you implement Forth the easy way (like, e.g., Machine Forth), you
lose quite a bit of performance: Machine Forth keeps the TOS in the
register and the rest of the stack in memory. If you do something
like "5 +", the "5" stores the old TOS to memory, and the "+" loads it
back from memory. This costs 5-6 cycles of latency on one of the
higher-performance Intel CPUs of the last few years.
A stack machine would avoid that problem, and, if implemented with
comparable technology as the Intel CPUs, would be quite a bit faster
on this kind of code. Alternatively, one can have a more
sophisticated compiler that keeps stack items in register and avoids
this kind of problem. In that case the stack machine has no
performance advantage; a stack machine with in-order execution would
be much simpler, but would not benefit from superscalar execution
enabled by out-of-order execution, so I guess the Intel CPU would be
faster, although at a huge cost in CPU complexity.
>When I designed my stack machine I gave it some features that were
>actually more efficient than the Forth virtual machine such as use of
>the return stack to hold and manipulate addresses separate from data.
>So maybe it is the Forth VM itself that limits efficiency.
There are some things, like implementing MOVE, where classic Forth is
not particularly good. The classic answer is that these are the kinds
of things classically written in assembly language. Of course, if the
assembly language of the CPU is Forth, that answer does not help, so
Charles Moore and others have added a few address registers: IIRC one
variant has A (a separate register) and R (the top of return stack); I
dimly remember that another address register B also occured in the
discussions.
That's certainly a good answer to the implementing-MOVE problem. When
that came up, some people also wondered whether we should not add A
etc. to Forth as a programming language. That discussion seems to
have died down without anyone (but Charles Moore) adding A to their
Forth system. I guess some are happy with the drop-to-assembly
solution, and others use locals or other solutions when there are too
many values used in the inner loop than fit comfortably on the stack.
- 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-16 07:38 -0700 |
| Message-ID | <30c2ae92-b73f-416b-aba0-5053979b62db@googlegroups.com> |
| In reply to | #47187 |
On Monday, May 16, 2016 at 5:52:05 AM UTC-7, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: > >I'm a bit surprised to hear anyone say implementing Forth on an x86 is > >anything but easy... well as easy as it would be on any CPU including > >stack machines. The primary difference between a stack machine and the > >x86 is the lack of flexibility in the stack machine. An x86 processor > >can do all the stack manipulations the stack machine can do as well as > >any manner of optimizations made possible by the register set and hugely > >flexible addressing modes. > > If you implement Forth the easy way (like, e.g., Machine Forth), you > lose quite a bit of performance: Machine Forth keeps the TOS in the > register and the rest of the stack in memory. If you do something > like "5 +", the "5" stores the old TOS to memory, and the "+" loads it > back from memory. This costs 5-6 cycles of latency on one of the > higher-performance Intel CPUs of the last few years. Well, lets look at SwiftForth: : 8+ 8 + ; ok see 8+ 491DEF 8 # EBX ADD 83C308 491DF2 RET C3 ok They have optimization on addition of literal values. : 8* 8 * ; ok see 8* 491E0F 8 # EAX MOV B808000000 491E14 EBX MUL F7E3 491E16 EAX EBX MOV 8BD8 491E18 RET C3 ok They don't have optimization on multiplication of literal values. : 8/ 8 / ; ok see 8/ 491E2F EBX EAX MOV 8BC3 491E31 CDQ 99 491E32 8 # EBX MOV BB08000000 491E37 EBX IDIV F7FB 491E39 EAX EBX MOV 8BD8 491E3B RET C3 ok They don't have optimization on division of literal values. As usual, my novice-package works around the problems in SwiftForth. See 1ARRAY etc. that use LIT*, to generate efficient multiplication of literal values.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-05-16 14:56 +0000 |
| Message-ID | <2016May16.165623@mips.complang.tuwien.ac.at> |
| In reply to | #47196 |
hughaguilar96@gmail.com writes:
>On Monday, May 16, 2016 at 5:52:05 AM UTC-7, Anton Ertl wrote:
>> If you implement Forth the easy way (like, e.g., Machine Forth), you
>> lose quite a bit of performance: Machine Forth keeps the TOS in the
>> register and the rest of the stack in memory. If you do something
>> like "5 +", the "5" stores the old TOS to memory, and the "+" loads it
>> back from memory. This costs 5-6 cycles of latency on one of the
>> higher-performance Intel CPUs of the last few years.
>
>Well, lets look at SwiftForth:
>
>: 8+ 8 + ; ok
>see 8+
>491DEF 8 # EBX ADD 83C308
>491DF2 RET C3 ok
>
>They have optimization on addition of literal values.
>
>: 8* 8 * ; ok
>see 8*
>491E0F 8 # EAX MOV B808000000
>491E14 EBX MUL F7E3
>491E16 EAX EBX MOV 8BD8
>491E18 RET C3 ok
>
>They don't have optimization on multiplication of literal values.
>
>: 8/ 8 / ; ok
>see 8/
>491E2F EBX EAX MOV 8BC3
>491E31 CDQ 99
>491E32 8 # EBX MOV BB08000000
>491E37 EBX IDIV F7FB
>491E39 EAX EBX MOV 8BD8
>491E3B RET C3 ok
>
>They don't have optimization on division of literal values.
None of these examples store the old TOS to memory in order to store
the 8 in EBC, the TOS register, like a naive compiler would. So
obviously SwiftForth is employing some optimization here. The
additional instructions are due to restrictions in the Intel MUL and
DIV instructions; however, there are variants of the IMUL instruction
that could be used in the 8* example instead and that would result in
fewer instructions.
To see what I mean, disable SwiftForth's optimization:
-opt ok
: 8+ 8 + ; ok
see 8+
8083BDF 4 # EBP SUB 83ED04
8083BE2 EBX 0 [EBP] MOV 895D00
8083BE5 8 # EBX MOV BB08000000
8083BEA 0 [EBP] EBX ADD 035D00
8083BED 4 # EBP ADD 83C504
8083BF0 RET C3 ok
- 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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-16 12:07 -0400 |
| Message-ID | <nhcr0b$1jg$1@dont-email.me> |
| In reply to | #47187 |
On 5/16/2016 8:21 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> I'm a bit surprised to hear anyone say implementing Forth on an x86 is >> anything but easy... well as easy as it would be on any CPU including >> stack machines. The primary difference between a stack machine and the >> x86 is the lack of flexibility in the stack machine. An x86 processor >> can do all the stack manipulations the stack machine can do as well as >> any manner of optimizations made possible by the register set and hugely >> flexible addressing modes. > > If you implement Forth the easy way (like, e.g., Machine Forth), you > lose quite a bit of performance: Machine Forth keeps the TOS in the > register and the rest of the stack in memory. If you do something > like "5 +", the "5" stores the old TOS to memory, and the "+" loads it > back from memory. This costs 5-6 cycles of latency on one of the > higher-performance Intel CPUs of the last few years. > > A stack machine would avoid that problem, and, if implemented with > comparable technology as the Intel CPUs, would be quite a bit faster > on this kind of code. Alternatively, one can have a more > sophisticated compiler that keeps stack items in register and avoids > this kind of problem. In that case the stack machine has no > performance advantage; a stack machine with in-order execution would > be much simpler, but would not benefit from superscalar execution > enabled by out-of-order execution, so I guess the Intel CPU would be > faster, although at a huge cost in CPU complexity. Not only would the register based machine be as fast, it can be faster since it can often skip the stack manipulation instructions required turning many instructions into noops. I don't write compilers, so I don't know how easy this sort of thing is, but it is entirely feasible. >> When I designed my stack machine I gave it some features that were >> actually more efficient than the Forth virtual machine such as use of >> the return stack to hold and manipulate addresses separate from data. >> So maybe it is the Forth VM itself that limits efficiency. > > There are some things, like implementing MOVE, where classic Forth is > not particularly good. The classic answer is that these are the kinds > of things classically written in assembly language. Of course, if the > assembly language of the CPU is Forth, that answer does not help, so > Charles Moore and others have added a few address registers: IIRC one > variant has A (a separate register) and R (the top of return stack); I > dimly remember that another address register B also occured in the > discussions. > > That's certainly a good answer to the implementing-MOVE problem. When > that came up, some people also wondered whether we should not add A > etc. to Forth as a programming language. That discussion seems to > have died down without anyone (but Charles Moore) adding A to their > Forth system. I guess some are happy with the drop-to-assembly > solution, and others use locals or other solutions when there are too > many values used in the inner loop than fit comfortably on the stack. I took a different tack with my CPU design. Seeing the issue of needing to pop two items from the stack on a write as well as the incongruity (in my opinion) if processing addresses on the data stack, I gave my return stack minimal math capabilities and treat it as the address stack. A memory operation uses the address on the top of the return stack and the data via the data stack allowing each to push/pop one operand. Otherwise I would have needed to add yet another data path. This allows the return stack to handle address increments/decrements and to process looping controls, although using both features requires moving data about. I combined this with a literal instruction which creates a literal on the return stack since most literals in Forth are used for addresses. If the literal is actually for the data stack it requires a move. So rather than adding an A register, I just use the return stack. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-16 09:18 -0700 |
| Message-ID | <87lh3anfhn.fsf@jester.gateway.pace.com> |
| In reply to | #47187 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > That's certainly a good answer to the implementing-MOVE problem. When > that came up, some people also wondered whether we should not add A > etc. to Forth as a programming language. That discussion seems to > have died down without anyone (but Charles Moore) adding A to their > Forth system. http://amforth.sourceforge.net/TG/recipes/Extended-VM.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-16 13:19 -0500 |
| Message-ID | <2IudnXskFpi2kqfKnZ2dnUU7-fHNnZ2d@supernews.com> |
| In reply to | #47187 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > rickman <gnuarm@gmail.com> writes: >>I'm a bit surprised to hear anyone say implementing Forth on an x86 is >>anything but easy... well as easy as it would be on any CPU including >>stack machines. The primary difference between a stack machine and the >>x86 is the lack of flexibility in the stack machine. An x86 processor >>can do all the stack manipulations the stack machine can do as well as >>any manner of optimizations made possible by the register set and hugely >>flexible addressing modes. > > If you implement Forth the easy way (like, e.g., Machine Forth), you > lose quite a bit of performance: Machine Forth keeps the TOS in the > register and the rest of the stack in memory. If you do something > like "5 +", the "5" stores the old TOS to memory, and the "+" loads it > back from memory. This costs 5-6 cycles of latency on one of the > higher-performance Intel CPUs of the last few years. > > A stack machine would avoid that problem, and, if implemented with > comparable technology as the Intel CPUs, would be quite a bit faster > on this kind of code. Alternatively, one can have a more > sophisticated compiler that keeps stack items in register and avoids > this kind of problem. In that case the stack machine has no > performance advantage; a stack machine with in-order execution would > be much simpler, but would not benefit from superscalar execution > enabled by out-of-order execution, so I guess the Intel CPU would be > faster, although at a huge cost in CPU complexity. But this advantage fails as soon as you're at a call site: then you have to do the grand shuffle to get all the arguments in the right place and save all of the call-clobbered registers onto the stack. A real stack machine doesn't need all of this stuff. As long as you can inline deeply and there are enough registers to hold temporaries, everything is fine, but deep inlining causes an explosion of complexity. The best JIT compilers only generate code for commonly-executed paths, and this allows very deep inlining. A lot of the time the overhead for calls simply goes away. That would work very well for Forth. > There are some things, like implementing MOVE, where classic Forth is > not particularly good. The classic answer is that these are the kinds > of things classically written in assembly language. Or alternatively that anyone implementing a Forth processor adds a few low-level instructions and a few registers. Like this on Novix: : move ( s d n) >r md i! i times 1 @+ md i@! r> times 1 !- drop ; The size of the MOVE is limited to the available stack space, but of course you can move a bigger quantity in batches. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-05-17 12:39 +0000 |
| Message-ID | <2016May17.143919@mips.complang.tuwien.ac.at> |
| In reply to | #47212 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> rickman <gnuarm@gmail.com> writes:
>>>I'm a bit surprised to hear anyone say implementing Forth on an x86 is
>>>anything but easy... well as easy as it would be on any CPU including
>>>stack machines. The primary difference between a stack machine and the
>>>x86 is the lack of flexibility in the stack machine. An x86 processor
>>>can do all the stack manipulations the stack machine can do as well as
>>>any manner of optimizations made possible by the register set and hugely
>>>flexible addressing modes.
>>
>> If you implement Forth the easy way (like, e.g., Machine Forth), you
>> lose quite a bit of performance: Machine Forth keeps the TOS in the
>> register and the rest of the stack in memory. If you do something
>> like "5 +", the "5" stores the old TOS to memory, and the "+" loads it
>> back from memory. This costs 5-6 cycles of latency on one of the
>> higher-performance Intel CPUs of the last few years.
>>
>> A stack machine would avoid that problem, and, if implemented with
>> comparable technology as the Intel CPUs, would be quite a bit faster
>> on this kind of code. Alternatively, one can have a more
>> sophisticated compiler that keeps stack items in register and avoids
>> this kind of problem. In that case the stack machine has no
>> performance advantage; a stack machine with in-order execution would
>> be much simpler, but would not benefit from superscalar execution
>> enabled by out-of-order execution, so I guess the Intel CPU would be
>> faster, although at a huge cost in CPU complexity.
>
>But this advantage fails as soon as you're at a call site: then you
>have to do the grand shuffle to get all the arguments in the right
>place and save all of the call-clobbered registers onto the stack.
No. In Forth the compiler knows what code a direct call calls, so
there is no need for a shuffle before or after a direct call. And of
course a compiler that makes use of that knowledge will avoid putting
data that lives across the direct call in a register that is clobbered
by the callee.
There are places where you cannot avoid register shuffling or
spilling, but they are relatively rare. And the out-of-order
execution works nicely across calls (even the heavy-weight C-style
calls you are thinking of). Indeed, recent generations of Intel CPUs
are able to perform register-to-register moves in 0 cycles, so even if
there is a shuffle, it can be pretty cheap.
> A
>real stack machine doesn't need all of this stuff.
The number of times stuff is shuffled with SWAP, ROT, or duplicated
with DUP, OVER is probably much higher then the number of places where
a sophisticated compiler for a register machine cannot avoid
shuffling.
>As long as you can
>inline deeply and there are enough registers to hold temporaries,
>everything is fine, but deep inlining causes an explosion of
>complexity.
Whether you inline deeply, or shallowly, I don't see much difference
in complexity; there is a difference in code size, however.
>The best JIT compilers only generate code for commonly-executed paths,
>and this allows very deep inlining. A lot of the time the overhead
>for calls simply goes away. That would work very well for Forth.
See! The trace-based approach is not what I was thinking of, but is
another way to get similar results.
- 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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-17 10:34 -0500 |
| Message-ID | <WbGdnY_WbO-Ep6bKnZ2dnUU7-RfNnZ2d@supernews.com> |
| In reply to | #47249 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> >>> A stack machine would avoid that problem, and, if implemented with >>> comparable technology as the Intel CPUs, would be quite a bit faster >>> on this kind of code. Alternatively, one can have a more >>> sophisticated compiler that keeps stack items in register and avoids >>> this kind of problem. In that case the stack machine has no >>> performance advantage; a stack machine with in-order execution would >>> be much simpler, but would not benefit from superscalar execution >>> enabled by out-of-order execution, so I guess the Intel CPU would be >>> faster, although at a huge cost in CPU complexity. >> >>But this advantage fails as soon as you're at a call site: then you >>have to do the grand shuffle to get all the arguments in the right >>place and save all of the call-clobbered registers onto the stack. > > No. In Forth the compiler knows what code a direct call calls, so > there is no need for a shuffle before or after a direct call. And of > course a compiler that makes use of that knowledge will avoid putting > data that lives across the direct call in a register that is clobbered > by the callee. OK, fair enough: you're assuming total visibility of everything. I'll grant this is true, and it means that no "ABI" per se is necessary apart from over e.g. EXECUTE. (And I'll note that "conventional" compilers use similar techiniques with inter-procedural optimization passes.) However, there is still a problem that the data required aren't always going to be in the most convenient registers as they would be when inlining, especially as you're going to be running out of registers a lot of the time. I'm curoious: does any Forth compiler do this? I accept your point about SWAP ROT BLAH not being free. >>As long as you can inline deeply and there are enough registers to >>hold temporaries, everything is fine, but deep inlining causes an >>explosion of complexity. > > Whether you inline deeply, or shallowly, I don't see much difference > in complexity; there is a difference in code size, however. There does tends to be an increase in complexity when inlining because of the increase in size: you usually need more registers and their live ranges increase, so the complexity of register allocation increases steeply along with the complexity of the control flow. >>The best JIT compilers only generate code for commonly-executed paths, >>and this allows very deep inlining. A lot of the time the overhead >>for calls simply goes away. That would work very well for Forth. > > See! ! > The trace-based approach is not what I was thinking of, but is > another way to get similar results. Indeed. The idea is to concentrate the firepower of the compiler on the best targets; trace compiling is one way to do that. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-05-17 15:54 +0000 |
| Message-ID | <2016May17.175426@mips.complang.tuwien.ac.at> |
| In reply to | #47254 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>However, there is still a problem that the data required
>aren't always going to be in the most convenient registers as they
>would be when inlining,
Sure, if you call the same word from two different places that are
also connected in other ways, you may not be able to adjust the
registers so that no place needs shuffling. The same is true for
control-flow joins. But then we have these nice zero-cycle MOVs on
recent Intel processors to the rescue.
> especially as you're going to be running out
>of registers a lot of the time.
I don't expect that to happen in those parts of the code that are
executed a lot. My own data indicate that stacks don't get very deep,
and Chuck Moore thinks that 6 stack items are enough. I expect that
EXECUTE/DEFER will be a much more frequent and dominating cause of
spilling; alternatively, in some code, calls to C functions.
>I'm curoious: does any Forth compiler do this?
AFAIK not yet, but I don't know what iForth is doing; maybe Marcel
Hendrix can enlighten us.
VFX goes back to the canonical stack representation (or ABI:-) on
every basic block boundary, including non-inlined calls.
>> Whether you inline deeply, or shallowly, I don't see much difference
>> in complexity; there is a difference in code size, however.
>
>There does tends to be an increase in complexity when inlining because
>of the increase in size: you usually need more registers and their
>live ranges increase, so the complexity of register allocation
>increases steeply along with the complexity of the control flow.
Ok, so you mean algorithmic (O(...)-Notation) complexity, not software
complexity. That seems to be an issue of choosing the right
algorithms and data structures. E.g., linear-scan register allocation
is reportedly pretty fast; it may not be most economical with
registers, but as mentioned above, I don't expect register numbers to
be a problem in frequently executed code parts anyway.
- 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]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-05-17 12:44 -0700 |
| Message-ID | <0c6a55f0-fe76-425b-9a41-479c4225e699@googlegroups.com> |
| In reply to | #47255 |
On Tuesday, May 17, 2016 at 6:21:23 PM UTC+2, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >However, there is still a problem that the data required > >aren't always going to be in the most convenient registers as they > >would be when inlining, > > Sure, if you call the same word from two different places that are > also connected in other ways, you may not be able to adjust the > registers so that no place needs shuffling. The same is true for > control-flow joins. But then we have these nice zero-cycle MOVs on > recent Intel processors to the rescue. AFAIK, the Intel FPU stack ops already work this way for many years. > > especially as you're going to be running out > >of registers a lot of the time. [..] > > AFAIK not yet, but I don't know what iForth is doing; maybe > Marcel Hendrix can enlighten us. I think Andrew's question was: >> OK, fair enough: you're assuming total visibility of >> everything. I'll grant this is true, and it means >> that no "ABI" per se is necessary apart from over >> e.g. EXECUTE. (And I'll note that "conventional" >> compilers use similar techiniques with inter-procedural >> optimization passes.) However, there is still a >> problem that the data required aren't always going >> to be in the most convenient registers as they >> would be when inlining, especially as you're going >> to be running out of registers a lot of the time. >> I'm curoious: does any Forth compiler do this? I can say that iForth keeps track of the prelude and postlude of most kernel words, and also of most user-defined words (obvious exceptions apart from EXECUTE are words containing I/O or OS-calls.) Another thing that happens is that inlining is a delayed two-stage process where the first stage generates intermediate code that the second stage interprets, compresses and assembles using the most appropriate / efficient / shortest SIB addressing mode. I'm speculating that SIB addressing will once become as fast as anything else. Under some conditions (almost always) the compiler by-passes the general housekeeping code of larger words that should not be inlined, optimizing the register content for a call/jmp with the lowest overhead. The compiler is already assuming what now seems to become reality: that register-register moves are free. If only pushes and pops were too :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-15 11:03 -0700 |
| Message-ID | <5fc58bbc-d742-4b25-aa89-6bfdcfc3d619@googlegroups.com> |
| In reply to | #47139 |
On Sunday, May 15, 2016 at 3:41:53 AM UTC-7, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: > >I have no idea why anyone would say a conventional processor designed to > >run C programs efficiently would not be suitable for running Forth. I > >don't know of any reason why the two would be mutually exclusive. > > Right. Forth is a language that was designed to be close to the > machine, so it's unsurprising that it can be implemented efficiently > on existing machines. It takes a more effort (and complexity) to > implement it very efficiently than a Forth implementation on a Forth > processor, though. But if you are prepared to sacrifice some run-time > efficiency for simplicity, compilation can be very simple: see machine > Forth for the 386. That is not true. Forth requires two stacks (data-stack and return-stack) whereas C requires one stack. This was a problem in the 1980s and early 1990s because the processors had very few registers. On the CPU08, for example, we had these registers: 8-bit A accumulator 16-bit S stack 16-bit H:X pointer The CPU08 was designed to support C. The local variables are on the S stack. The return-address is also on the S stack. The CPU08 won't support Forth very well though. This is because the return-stack is on the S stack on top of the parameters, so you can't move S up and down (as with DROP and OVER etc.). It is possible to implement Forth on a CPU08, but it is inefficient. In zero-page, every function has a 3-byte memory block associated with it containing this code: JMP 0000 On entry to the function, we have this code: PULA STA lo ; the low byte of the operand for the JMP associated with this function PULA STA hi ; the high byte of the operand for the JMP associated with this function On leaving the function (the code compiled by EXIT), we have a JMP to the JMP that is in zero-page and is associated with this function. This gets the return-address off the S stack during the function's execution so the S stack can be used as a data-stack in the usual Forth way. It is very inefficient compared to C though, because of all this extra code upon entrance and exit of every function. Also, it is not reentrant. Also, it wastes a lot of zero-page memory (3 bytes per function) and zero-page is where you want all of your global variables because it is much faster access, so this limits the size of the programs. Consider the CPU12, of the same era as the CPU08, which had these registers: 16-bit D accumulator 16-bit X pointer 16-bit Y pointer 16-bit SP stack Now we can dedicate one of the pointer registers to being the data-stack register (lets use Y). The problem is that we only have X available for general-purpose use. By comparison, C has both X and Y available. This is going to make Forth code less efficient than C code. A big part of the reason why Forth had a reputation in those days for being less efficient than C was because it is less efficient on a register-constrained processor. Also, the processors were designed to support C rather than Forth. Consider the CPU08 again: 8-bit A accumulator 16-bit S stack 16-bit H:X pointer This could have been designed differently to support Forth: 8-bit A accumulator 8-bit S data-stack 8-bit R return-stack 16-bit H:X pointer This design would have used the same amount of resources (total bits used in registers is the same), but it would have supported Forth. It would have supported C also --- C functions typically have a lot of local variables though, so the 256 byte data-stack might have overflowed in some programs --- that is really a problem with C though, so blaming the Forth for being more efficient in stack-memory usage wouldn't really be fair. Nowadays processors have a lot of registers. Even the MSP430, which is the least powerful processor in use today, has 16 16-bit registers. Within that context, it is okay for Forth to dedicate one of those registers to being the data-stack pointer --- there are still plenty of registers left available for general-purpose use. Most likely Anton Ertl was not programming in Forth in the early 1990s so he wasn't aware that processors had a shortage of registers in that era. Also, Rickman is the chief sycophant of the Forth-200x committee, and Anton Ertl is the chair-person of the Forth-200x committee, so Anton Ertl felt obliged to support Rickman's ignorant proclamation. Going on c.l.f. and making statements that are untrue tends to hurt the credibility of the Forth community though --- it is better to just be truthful --- Elizabeth Rather has always hurt the credibility of the Forth community because she is a pathological liar, so it is very bad when the Forth-200x chair-person also makes untrue statements in public.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-15 21:56 -0400 |
| Message-ID | <nhb95g$ptu$1@dont-email.me> |
| In reply to | #47152 |
On 5/15/2016 2:03 PM, hughaguilar96@gmail.com wrote: > On Sunday, May 15, 2016 at 3:41:53 AM UTC-7, Anton Ertl wrote: >> rickman <gnuarm@gmail.com> writes: >>> I have no idea why anyone would say a conventional processor >>> designed to run C programs efficiently would not be suitable for >>> running Forth. I don't know of any reason why the two would be >>> mutually exclusive. >> >> Right. Forth is a language that was designed to be close to the >> machine, so it's unsurprising that it can be implemented >> efficiently on existing machines. It takes a more effort (and >> complexity) to implement it very efficiently than a Forth >> implementation on a Forth processor, though. But if you are >> prepared to sacrifice some run-time efficiency for simplicity, >> compilation can be very simple: see machine Forth for the 386. > > That is not true. <<<snip>>> ... As usual Hugh sees things with blinders. We were discussing the suitability of the x86 processor. Yes, I generalized to any processor intended to run C, but a 6805 CPU.... really? I don't think it was really designed to run C. There may have been C compilers, but there is a C compiler for the RTX2000. Is that chip designed to run C? Anyway, it was an excuse for Hugh to rant a bit. I hope he worked it out and will settle down now. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-15 19:02 -0700 |
| Message-ID | <87shxioj4i.fsf@jester.gateway.pace.com> |
| In reply to | #47172 |
rickman <gnuarm@gmail.com> writes: > We were discussing the suitability of the x86 processor. Yes, I > generalized to any processor intended to run C, but a 6805 > CPU.... really? I don't think it was really designed to run C. I don't think the x86 was originally designed to run C either, particularly the original 16 bit versions. Later updates and extensions made it much more C friendly.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-15 20:03 -0700 |
| Message-ID | <393e3553-db4b-47d1-aaee-d3dbc6193968@googlegroups.com> |
| In reply to | #47174 |
On Sunday, May 15, 2016 at 7:02:22 PM UTC-7, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > We were discussing the suitability of the x86 processor. Yes, I > > generalized to any processor intended to run C, but a 6805 > > CPU.... really? I don't think it was really designed to run C. > > I don't think the x86 was originally designed to run C either, > particularly the original 16 bit versions. Later updates and extensions > made it much more C friendly. I was talking about the CPU08 --- Rickman is lying when he says that I was talking about the 6805. On the subject of the 6805 however, Skip Carter told me in private correspondence that he wrote a cross-compiler for it. I asked if he used self-modifying code to get @ and ! to work, and he said yes. This was used in a buoy out in the ocean. This conversation occurred a long time ago --- I think it was after I wrote my 65c02 cross-compiler but before I worked at Testra and wrote MFX for the MiniForth, so about 25 years ago. As for the 16-bit x86, I'm pretty sure that it was intended to be used with C. The BP register was supposed to be the frame-pointer. It worked pretty well with Forth too. I wrote some benchmark programs in both UR/Forth and Borland Turbo-C (Small memory-model) and found the speed to be almost exactly the same.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-16 02:13 -0400 |
| Message-ID | <nhbo7c$ulm$1@dont-email.me> |
| In reply to | #47174 |
On 5/15/2016 10:02 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> We were discussing the suitability of the x86 processor. Yes, I >> generalized to any processor intended to run C, but a 6805 >> CPU.... really? I don't think it was really designed to run C. > > I don't think the x86 was originally designed to run C either, > particularly the original 16 bit versions. Later updates and extensions > made it much more C friendly. While it has always been a pretty good Forth engine even if it is very, very much overkill. I'm sure what the x86 has become is a very good CPU, but sometimes it just boggles my mind that we have gotten here. The complexity really is amazing, the i7 has 1.4 BILLION transistors!!! I wonder if in a few millennia we will be researched by archeologists looking at the amazingly intricate silicon mosaic-like artwork and they wonder what the heck it is for and how it was used? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-16 00:37 -0700 |
| Message-ID | <73f98bf5-0ee2-4155-8393-58d36ed68ca6@googlegroups.com> |
| In reply to | #47182 |
Well I believe it has to do with manufacturers taking "Moore's Law" to heart. Since this assumption by Moore was made in the 60s and calculating the number of iterations (doubling in power ever 18 months). Now that they are reaching the end they are going with multicores to offset it. I feel that a software collapse will occur in 10 years or less looking at how complicated software as become and hardware won't able to keep up with it. That's why I'm studying forth! Forth will have its day that I truly believe. Not because it cannot be complicated if used incorrectly, but because those who are so used to working in and teaching in the small truly have the advantage.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-05-16 13:41 +0000 |
| Message-ID | <2016May16.154124@mips.complang.tuwien.ac.at> |
| In reply to | #47184 |
murphy.darin@gmail.com writes:
>Well I believe it has to do with manufacturers taking "Moore's Law" to hear=
>t. Since this assumption by Moore was made in the 60s and calculating the n=
>umber of iterations (doubling in power ever 18 months).
Moore's law has always been about transistors-per-chip, not about
power or anything else; in 1965 he predicted doubling every 12 months
for 10 years, in 1975 he revisited it and predicted doubling every 18
months for 10 years.
The development of CPU single-core performance has been called the
"not-Moore's law", and recently I have seen the term "Dennard scaling"
used for it, although that is also about something else
<https://en.wikipedia.org/wiki/Dennard_scaling>.
> Now that they are r=
>eaching the end they are going with multicores to offset it. I feel that a =
>software collapse will occur in 10 years or less looking at how complicated=
> software as become and hardware won't able to keep up with it.
We have had failed software projects since at least the 1960s
("software crisis", "Mythical man-month"). Software is getting more
complex because hardware is offering more resources. If hardware
stops offering more resources, I wonder how long the software industry
will progress further, or if, say, 10 years later, all worthwhile
programs for using the now-fixed hardware are written, and the
software industry will see huge layoffs.
- 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]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-05-16 21:42 +0000 |
| Message-ID | <nhdet2$d2i$1@dont-email.me> |
| In reply to | #47193 |
Am Mon, 16 May 2016 13:41:24 +0000 schrieb Anton Ertl:
> We have had failed software projects since at least the 1960s ("software
> crisis", "Mythical man-month"). Software is getting more complex
> because hardware is offering more resources. If hardware stops offering
> more resources, I wonder how long the software industry will progress
> further, or if, say, 10 years later, all worthwhile programs for using
> the now-fixed hardware are written, and the software industry will see
> huge layoffs.
Software developers will use all available resources, because they are
lazy, and have the fastest machines. If progress on hardware stops (e.g.
because Moore's law hits the physical limits), then it will be more
important to optimize better. This will consume more time, and require
more talented developers, so maybe there will be some layoffs.
--
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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-16 16:23 -0700 |
| Message-ID | <f3ec017c-8161-4b80-a7dc-a6acd5f3b5ee@googlegroups.com> |
| In reply to | #47219 |
On Monday, May 16, 2016 at 2:46:34 PM UTC-7, Bernd Paysan wrote:
> Am Mon, 16 May 2016 13:41:24 +0000 schrieb Anton Ertl:
> > We have had failed software projects since at least the 1960s ("software
> > crisis", "Mythical man-month"). Software is getting more complex
> > because hardware is offering more resources. If hardware stops offering
> > more resources, I wonder how long the software industry will progress
> > further, or if, say, 10 years later, all worthwhile programs for using
> > the now-fixed hardware are written, and the software industry will see
> > huge layoffs.
>
> Software developers will use all available resources, because they are
> lazy, and have the fastest machines. If progress on hardware stops (e.g.
> because Moore's law hits the physical limits), then it will be more
> important to optimize better. This will consume more time, and require
> more talented developers, so maybe there will be some layoffs.
Actually, most programs don't require a very fast computer. There are some things that are possible now because we have fast computers, and which weren't possible in the past (speech recognition, for example). For the most part though, the computer is faster than it needs to be. The GUI consumes most of the computer's resources, and it is just cuteness --- it doesn't really provide any capability that could just as well have been provided with a text console --- a text console is actually more powerful because it uses written language, whereas GUI pointing-and-clicking uses icons similar to what humans used before the alphabet was invented (GUI icons are essentially just hieroglyphs).
A lot of people have said that, if planes had advanced as fast as computers, we would have been to the Moon 10 years after the Wright Brothers flight, and would now be colonizing other planets. Somebody once retorted that if planes had advanced the same way as software, we would now have jets that crashed 5% of the time that they were flown, and which were used to haul garbage.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web