Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16579 > unrolled thread
| Started by | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| First post | 2012-10-22 08:53 -0700 |
| Last post | 2012-10-23 10:52 +0000 |
| Articles | 20 on this page of 172 — 22 participants |
Back to article view | Back to comp.lang.forth
RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-22 08:53 -0700
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 11:21 -0500
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 09:56 -0700
Re: RTX2000 optimization Mark Wills <forthfreak@gmail.com> - 2012-10-22 12:10 -0700
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 12:55 -0700
Re: RTX2000 optimization Coos Haak <chforth@hccnet.nl> - 2012-10-22 22:02 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-22 16:50 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 21:52 -0400
Re: RTX2000 optimization Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 22:03 -0700
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-23 03:19 -0500
Re: RTX2000 optimization vandys@vsta.org - 2012-10-23 17:54 +0000
Re: RTX2000 optimization Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 08:16 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:19 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 06:56 -0400
Re: RTX2000 optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-24 12:26 +0000
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 15:25 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:30 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:10 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 16:43 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 17:55 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:44 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 02:17 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 23:01 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 22:18 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-27 19:19 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-28 04:21 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 14:36 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-29 19:06 -0400
Re: RTX2000 optimization Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-30 02:07 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-30 09:36 -0400
Re: RTX2000 optimization Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-30 08:09 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-30 19:14 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-30 18:50 -0400
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-31 07:37 -0700
Re: RTX2000 optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-31 15:27 +0000
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-31 08:59 -0700
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-31 11:18 -0500
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-31 13:49 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-31 13:43 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 12:03 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Mark Wills <forthfreak@gmail.com> - 2012-10-31 09:05 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] daveyrotten <danw8804@gmail.com> - 2012-10-31 09:06 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-10-31 09:25 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] danw8804@gmail.com - 2012-10-31 09:38 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-10-31 14:30 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-10-31 14:27 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-10-31 12:01 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-10-31 16:31 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-10-31 20:33 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-01 14:05 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-01 11:23 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-01 14:31 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-02 22:11 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 12:50 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-03 10:42 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 13:59 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-03 12:10 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 15:42 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-03 15:56 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 20:53 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-04 11:10 +0000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-04 22:58 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 15:29 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 14:40 +0000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-05 11:36 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-05 09:02 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-05 15:22 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-05 12:56 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 12:22 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-06 09:29 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 12:53 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-06 10:00 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-06 08:04 -1000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 13:37 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 21:06 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-05 15:29 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-06 16:28 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 12:50 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-07 20:29 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-04 10:40 +0000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-01 21:26 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-01 13:44 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-02 04:03 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] David Schultz <abuse@127.0.0.1> - 2012-11-04 17:17 -0600
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-11-02 12:48 -0700
Re: RTX2000 optimization "Elizabeth D. Rather" <erather@forth.com> - 2012-11-02 10:25 -1000
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-11-02 19:54 -0700
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 17:47 +0100
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-11-03 14:05 -0400
Re: RTX2000 optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 11:55 +0000
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-11-03 19:20 -0700
Re: RTX2000 optimization mhx@iae.nl (Marcel Hendrix) - 2012-11-04 16:08 +0200
Re: RTX2000 optimization mhx@iae.nl (Marcel Hendrix) - 2012-11-04 17:14 +0200
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-04 18:40 +0100
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 09:36 -0600
Re: RTX2000 optimization Andy Valencia <vandys@vsta.org> - 2012-11-04 23:49 +0000
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-31 12:11 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 20:08 -0400
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-11-01 10:59 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-11-01 12:12 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-11-01 12:14 -0700
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-11-02 10:51 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-11-02 11:28 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-11-01 14:58 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 14:45 +0100
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 15:04 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 21:09 +0100
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 16:59 -0400
Re: RTX2000 optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-28 07:59 +0000
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 15:06 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 16:35 -0400
Re: RTX2000 optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 12:44 +0000
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:32 -0400
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-22 13:54 -0700
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 14:14 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-22 14:26 -0700
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 16:00 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 21:51 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:36 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 08:47 -0400
Re: RTX2000 optimization Alex McDonald <blog@rivadpm.com> - 2012-10-24 06:36 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 15:33 -0400
Re: RTX2000 optimization Alex McDonald <blog@rivadpm.com> - 2012-10-25 04:54 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 17:35 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 15:27 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 19:10 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 18:34 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:03 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:56 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 18:34 +0200
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 22:27 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:27 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:17 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:44 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:59 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:42 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:55 -0400
Re: RTX2000 optimization Alex McDonald <blog@rivadpm.com> - 2012-10-25 04:49 -0700
addressable stack, was [Re: RTX2000 optimization] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-05 14:04 -0500
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 15:44 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:50 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 18:58 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 16:07 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 19:20 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 20:57 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-27 15:43 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-28 05:01 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 15:23 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-29 19:32 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-30 19:00 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 01:23 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-31 14:56 -0400
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 19:44 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:47 -0400
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-23 16:00 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 21:07 -0400
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-23 18:44 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 16:03 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:15 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 16:25 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 03:15 +0200
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 09:55 -0700
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 10:04 -0700
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 12:00 -0700
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 23:24 -0700
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-25 09:26 -0700
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 10:39 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 19:35 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 18:26 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 16:10 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:21 -0700
Re: RTX2000 optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 10:52 +0000
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-01 21:26 +0100 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <3373483.N4T9SRI6tE@sunwukong.fritz.box> |
| In reply to | #16951 |
Paul Rubin wrote: > What I want to know is what it takes to > get from Verilog to rectangles, and how much more complicated the > other stuff is than it used to be. When I started the 4stack processor design, I looked for free available tools, and there was an "Alliance" suite developed in France; they are still developing their software, the last release is from 2007: http://linux.softpedia.com/get/Science-and-Engineering/Electronic- Design-Automation-EDA-/Alliance-CAD-System-1936.shtml They don't have a Verilog frontend, VDHL only. And I don't think it's a realistic competition to the expensive software from Cadence or Synopsys. But this is a complete framework, from VHDL to "rectangles" aka GDSII (the typical elements there are pathes and polygons, though you usually are only allowed 45° and 90° angles). The pricing in the EDA and silicon manufacturing environment is horrible. I once wrote a GDSII toolkit in Forth (I still have it with me, it's just 400 lines of code), because our fab wanted to charge us 5000 Euro for each run of a ROM generator, in addition to the mask costs of a new ROM... It took me an hour to write my own ROM generator using that tool - to generate the contacts that represent data bits. The toolkit can read GDSII, convert it to ASCII and reverse, and can create GDSII, insert data into, or remove data from it (and even create printable PostScript). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-01 13:44 -0700 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7x7gq5jbna.fsf@ruckus.brouhaha.com> |
| In reply to | #16956 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Design-Automation-EDA-/Alliance-CAD-System-1936.shtml > They don't have a Verilog frontend, VDHL only. And I don't think it's a > realistic competition to the expensive software from Cadence or > Synopsys. Interesting, thanks. My guess is a Verilog front end wouldn't be that big a task to add. > The pricing in the EDA and silicon manufacturing environment is > horrible. Yeah, that's unfortunate. It looks like small-quantity VLSI in older processes is surprisingly affordable: http://cmp.imag.fr/products/ic/?p=prices you can get a chip made in 0.35u for around 2000 euro (3 mm^2 chip area, 25 dice). That's outside most recreational budgets but certainly within reach if you're doing something serious. So better free tools would be a big win.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-02 04:03 -0400 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k6vugj$4cr$1@speranza.aioe.org> |
| In reply to | #16951 |
"Paul Rubin" <no.email@nospam.invalid> wrote in message news:7xlielw5a9.fsf@ruckus.brouhaha.com... > rickman <gnuarm@gmail.com> writes: > > Please don't get me wrong. The synthesis is not easy. ... > > Thanks. I just came across this, by a guy who made his own FPGA from > 7400-series parts: > > http://blog.notdot.net/2012/10/Build-your-own-FPGA > > It demystified FPGA's a lot for me and I think I have sort of a clue now > about how the tools might work. > Many years ago, there was an article in Byte magazine where a cpu was made from discrete parts. I don't recall, but I suspect they were probably 7400-series. And, I'm not sure if it was Steve Ciarcia (electronics author) or someone else. http://en.wikipedia.org/wiki/Steve_Ciarcia If you go to a site like Hackaday.com, you'll see all sorts of projects. Many are electronic, microcontroller, and programming related, but plenty of other stuff too. There are guys retrofitting old CNC machines to work with microcontrollers or modern software or route PCBs. Other guys developing custom circuits to drive salvaged laptop displays. All sorts of robotics stuff. There are probably some custom cpu's in there too. They do catalog or index their posts. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2012-11-04 17:17 -0600 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <GICls.550547$eR7.525711@en-nntp-16.dc1.easynews.com> |
| In reply to | #16927 |
On 10/31/2012 10:33 PM, Paul Rubin wrote: > I wonder what the situation > is with custom silicon, where you just have to make rectangle layout. > There's not any secret formats in that instance, but there's still not > any FOSS tools as far as I know. There are are lower level FOSS tools > like layout editors but nothing to drop Verilog code in and get a > layout AFAIK. > It appears that at least one group has used the old LagerIV tools to do something close. They wrote a frontend to convert from VHDL to the format expected by LagerIV. http://www.eda.org/VIUF_proc/Spring93/VEMURI93A.PDF There is almost a link to the old LagerIV source on the magic pages: http://opencircuitdesign.com/magic/download.html But if you start here you will get a directory listing which shows a Lager subdirectory. http://opencircuitdesign.com/magic/archive/ -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2012-11-02 12:48 -0700 |
| Message-ID | <716d61f6-ca70-4dc3-b9d8-d0f0c8eab91a@googlegroups.com> |
| In reply to | #16862 |
On Wednesday, October 31, 2012 7:37:18 AM UTC-7, daveyrotten wrote: > With all due respect, however, I don't get too excited about all the (what seems to me) nitpicking about which architecture is slightly faster than which other one. It seems to me that any processor which executes Forth opcodes directly as primitives, as the b16 and j1 do, has got to be an order of magnitude faster than a Forth system built on top of another language (even assembly language). Of course, in an FPGA you can hook in custom hardware anywhere you want to speed up the system. I would rather just build stuff than worry endlessly about whether it's faster than the next guy's approach. But that's just me. There are commercial Forths that compile Forth to classic RISC/CISC targets very efficiently using complex compilers that took man years to write. The Forth chips are closely matched to the source language so anyone can make a simple but decent compiler for them. You don't have to worry about obscure compiler bugs lurking for years. It's interesting to see the 2:1 C to Forth object code ratio with the J1 (almost 3:1 because Microblaze is a poofy ISA), since that has been the experience of Forth shops over the years. There's probably a mathematical explanation for the reason why compiled Forth is half the size of compiled C with a good compiler. OTOH, I've read that HiTech's "omniscient code generation" compiles to half the size of typical C. So maybe at an application level, classic C compilers simply can't "let all of the air out". With a Forth CPU and simple compiler, you're just not building air in.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-02 10:25 -1000 |
| Message-ID | <Y4adncSSYfyrsQnNnZ2dnUVZ_oGdnZ2d@supernews.com> |
| In reply to | #16995 |
On 11/2/12 9:48 AM, Brad Eckert wrote: > On Wednesday, October 31, 2012 7:37:18 AM UTC-7, daveyrotten wrote: > >> With all due respect, however, I don't get too excited about all the (what seems to me) nitpicking about which architecture is slightly faster than which other one. It seems to me that any processor which executes Forth opcodes directly as primitives, as the b16 and j1 do, has got to be an order of magnitude faster than a Forth system built on top of another language (even assembly language). Of course, in an FPGA you can hook in custom hardware anywhere you want to speed up the system. I would rather just build stuff than worry endlessly about whether it's faster than the next guy's approach. But that's just me. > > There are commercial Forths that compile Forth to classic RISC/CISC targets very efficiently using complex compilers that took man years to write. The Forth chips are closely matched to the source language so anyone can make a simple but decent compiler for them. You don't have to worry about obscure compiler bugs lurking for years. > > It's interesting to see the 2:1 C to Forth object code ratio with the J1 (almost 3:1 because Microblaze is a poofy ISA), since that has been the experience of Forth shops over the years. There's probably a mathematical explanation for the reason why compiled Forth is half the size of compiled C with a good compiler. OTOH, I've read that HiTech's "omniscient code generation" compiles to half the size of typical C. So maybe at an application level, classic C compilers simply can't "let all of the air out". > > With a Forth CPU and simple compiler, you're just not building air in. > Forth has greater code density than C because of its extreme modularity, coupled with the fact that a CALL in Forth doesn't do any of the "calling sequence" packaging that C subroutine calls do. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-02 19:54 -0700 |
| Message-ID | <7xpq3vtmzg.fsf@ruckus.brouhaha.com> |
| In reply to | #16995 |
Brad Eckert <hwfwguy@gmail.com> writes: > There's probably a mathematical explanation for the reason why > compiled Forth is half the size of compiled C with a good > compiler. It could be that the C programs are simply doing more. Part of the zen of Forth is to redefine the problem and strip out anything that the goal can be accomplished without. It's also not entirely fair to compare a 16-bit Forth target with an 8-bit C target, since the 8-bit code will bloat up with double-byte moves etc. > OTOH, I've read that HiTech's "omniscient code generation" compiles to > half the size of typical C. So maybe at an application level, classic > C compilers simply can't "let all of the air out". I looked this up and "omniscient code generation" looks to basically be marketing-speak for what compiler writers usually call whole-program optimization, i.e. interprocedural CSE and register allocation, that sort of thing. According to their numbers they did get considerable code size benefits, though closer to 30% than 50%. > With a Forth CPU and simple compiler, you're just not building air in. OTOH, to some extent it's simply shifting work from the compiler to the user.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-03 17:47 +0100 |
| Message-ID | <1413599.g8YLPlRKUt@sunwukong.fritz.box> |
| In reply to | #17006 |
Paul Rubin wrote: > Brad Eckert <hwfwguy@gmail.com> writes: >> There's probably a mathematical explanation for the reason why >> compiled Forth is half the size of compiled C with a good >> compiler. > > It could be that the C programs are simply doing more. Part of the > zen of Forth is to redefine the problem and strip out anything that > the goal > can be accomplished without. It's also not entirely fair to compare a > 16-bit Forth target with an 8-bit C target, since the 8-bit code will > bloat up with double-byte moves etc. We had a student trying to create a C backend for the b16 CPU, using one of those with a stack based intermediate language - the C frontend wrote the intermediate language out and then the student wrote his own backend, which, given that the b16 is already a stack processor, was not very complicated. Code densitry however fell considerably, because in C, you absolutely *must* handle locals. The student wrote some simple code to use a normal locals stack, and that was really a lot of overhead compared to Forth code doing the same. Even if the b16 had something like the Transputer workspace, the C code still would be considerably larger than Forth code. I'd say: Forth code with a simple native code compiler (like bigForth) on a C-optimized CPU is about 2 times slower than C (you don't use all the registers). C code on a simple Forth CPU is at least 2 times slower than Forth. >> With a Forth CPU and simple compiler, you're just not building air >> in. > > OTOH, to some extent it's simply shifting work from the compiler to > the user. If you are fluent in C and not in Forth, it might look like that. When I started as student, I was fluent in Forth, but the introduction course used Modula II. One of the task was roman numerals (see for example Thinking Forth about how to do that in Forth). When I did that exercise, I first wrote the program in Forth - this was just one screen, i.e. not even 16 lines. And then I converted the solution to Modula II, because that way, it was already tested and it was easy to write. The Modula II solution took one page (60 lines), it was by far the smallest solution to this exercise ever; the solution from the tutors was IIRC 5 pages long. What I had to build manually in Modula II is the pictured number buffer, whereas in Forth, I could just use HOLD. Especially in the Modula II case, I didn't feel the compiler helped me in any way. The language requires a considerable amount of boilerplate for anything, having named local variables and calling paramenters is a waste of time for essential one-lines (which, in Modula II, quickly have four of five lines), etc. IMHO, the compiler in a language like Modula II does nothing better than a Forth compiler, but it gets significantly into my way. E.g. returning more than one value from a subroutine is very cumbersome. IMHO the problem is that humans don't think the way the machine work. The Algol approach is to make the machine work the way humans have been taught to think by mathematics. The Forth approach is to make the human think the way the machine works, by creating a simpified machine (which then is easier to understand). It's just that simple: The human is still way more intelligent than the machine, and can learn to think that way; faster so, if the machine is simpler. Learning to think the Algol way was considerably harder for me than learning to think the Forth way. So what's the point of moving the communication interface further away from both human and machine (the machine is more complicated to execute Algol-like languages, and the boilerplate makes it more work to program)? -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-03 14:05 -0400 |
| Message-ID | <k73me7$gf2$1@dont-email.me> |
| In reply to | #17011 |
On 11/3/2012 12:47 PM, Bernd Paysan wrote: > Paul Rubin wrote: > >> Brad Eckert<hwfwguy@gmail.com> writes: >>> There's probably a mathematical explanation for the reason why >>> compiled Forth is half the size of compiled C with a good >>> compiler. >> >> It could be that the C programs are simply doing more. Part of the >> zen of Forth is to redefine the problem and strip out anything that >> the goal >> can be accomplished without. It's also not entirely fair to compare a >> 16-bit Forth target with an 8-bit C target, since the 8-bit code will >> bloat up with double-byte moves etc. > > We had a student trying to create a C backend for the b16 CPU, using one > of those with a stack based intermediate language - the C frontend wrote > the intermediate language out and then the student wrote his own > backend, which, given that the b16 is already a stack processor, was not > very complicated. > > Code densitry however fell considerably, because in C, you absolutely > *must* handle locals. The student wrote some simple code to use a > normal locals stack, and that was really a lot of overhead compared to > Forth code doing the same. Even if the b16 had something like the > Transputer workspace, the C code still would be considerably larger than > Forth code. But a C compiler can optimize to use registers in place of locals on the stack or anywhere else in memory. I guess it is a harder task to optimize to use a stack efficiently? > I'd say: Forth code with a simple native code compiler (like bigForth) > on a C-optimized CPU is about 2 times slower than C (you don't use all > the registers). C code on a simple Forth CPU is at least 2 times slower > than Forth. Of the four combinations, which is faster, that's the real question, eh? Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-05 11:55 +0000 |
| Message-ID | <2012Nov5.125535@mips.complang.tuwien.ac.at> |
| In reply to | #17018 |
rickman <gnuarm@gmail.com> writes:
>On 11/3/2012 12:47 PM, Bernd Paysan wrote:
>> We had a student trying to create a C backend for the b16 CPU, using one
>> of those with a stack based intermediate language - the C frontend wrote
>> the intermediate language out and then the student wrote his own
>> backend, which, given that the b16 is already a stack processor, was not
>> very complicated.
>>
>> Code densitry however fell considerably, because in C, you absolutely
>> *must* handle locals. The student wrote some simple code to use a
>> normal locals stack, and that was really a lot of overhead compared to
>> Forth code doing the same. Even if the b16 had something like the
>> Transputer workspace, the C code still would be considerably larger than
>> Forth code.
>
>But a C compiler can optimize to use registers in place of locals on the
>stack or anywhere else in memory. I guess it is a harder task to
>optimize to use a stack efficiently?
Not particularly. Martin Maierhofer looked at this in his Diploma
thesis, and found that a simple approach (stack scheduling) led to
results that are close to optimal. However, he only looked at
optimizing straight-line code. Things get more interesting and
complex if you want to keep C local variables on the stack across
control structures.
@MastersThesis{maierhofer97,
author = {Martin Maierhofer},
title = {Erzeugung optimierten Codes f\"{u}r Stackmaschinen},
school = {{Technische Universit\"{a}t Wien}},
type = {Diplomarbeit},
year = {1997},
address = {Austria},
url = {http://www.complang.tuwien.ac.at/Diplomarbeiten/maierhofer97.ps.gz},
abstract = {The success of the Java programming language and the
underlying stack architecture (the JavaVM) recently
have caused renewed interest in stack architectures.
New and special techniques are required to provide
support for the efficient execution of Algol-like
high level languages on stack machines. An optimizing
compiler should be able to eliminate dispensable
accesses to main memory when loading and storing local
variables by temporarily keeping a copy of their value
on the stack. This technique, however, is only
meaningful for machines that can handle
stackmanipulations faster than accesses to main
memory. \par This thesis presents two solutions for
the problem and compares the results that can be
achieved for two stack architectures (one of them is
the JavaVM). Both techniques work on a ``local'' level,
meaning that each basic block is considered separately.
Phil Koopman's ``stack scheduling'' performs well in
cooperation with a simple instruction scheduling
strategy (a depth first postorder traversal of the
dependency graph is used). The second technique
(``{\scshape Dag} scheduling'') reorders the
instructions (i.e. it schedules the instructions) in
order to minimize accesses to local variables and
leads to optimal code. \par The efficiency of Koopman's
algorithm can be assessed with respect to the results
achieved by {\scshape Dag} scheduling: stack scheduling
leads to results that come quite near the optimum.
Accesses to variables can be reduced from around 40\%
(in code produced by the Java compiler \texttt{javac})
to some 30\% (after optimization) of the total
instructions in JavaVM code. Instructions for
stackmanipulation, however, increase from about 5\% to
up to 15\% of the total.},
note = {In German}
}
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-03 19:20 -0700 |
| Message-ID | <7xpq3u3y8w.fsf@ruckus.brouhaha.com> |
| In reply to | #17011 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> We had a student trying to create a C backend for the b16 CPU, using one
> of those with a stack based intermediate language
I think the usual notion of "stack based intermediate language" includes
the ability to reach into the interior of the stack, which the b16
doesn't have a way to do. So I can understand why the compiler would
have to turn the IL into rather poor b16 code.
> Even if the b16 had something like the Transputer workspace, the C
> code still would be considerably larger than Forth code.
I wonder how it would compare to conventional register code.
> ... roman numerals in Forth - this was just one screen,
> i.e. not even 16 lines....
> The Modula II solution took one page (60 lines), it was by far the
> smallest solution to this exercise ever; the solution from the tutors
> was IIRC 5 pages long. What I had to build manually in Modula II is the
> pictured number buffer, whereas in Forth, I could just use HOLD.
In "horizontal style" Forth you can put a lot of operations on a line,
so you use fewer LOC than vertical style, but you're not really writing
less code. If the exercise is similar to the one in Thinking Forth
(p. 122) then 60 lines sounds excessive and 5 pages is ridiculous. In
that example (and the Thinking Forth treatment is pretty painful) there
is no pictured number buffer since the roman output word just writes to
the screen.
> having named local variables and calling paramenters is a waste of
> time for essential one-lines (which, in Modula II, quickly have four
> of five lines), etc.
I tried writing a C version (25 lines) and the simplest translation to
Forth would use named locals.
> IMHO, the compiler in a language like Modula II does nothing better than
> a Forth compiler, but it gets significantly into my way. E.g. returning
> more than one value from a subroutine is very cumbersome.
I haven't used Modula-2 but I'd have expected it to have in and out
parameters like Pascal or Ada? Anyway I don't see it as an issue, for
this particular problem.
> The Forth approach is to make the human think the way the machine
> works, by creating a simpified machine (which then is easier to
> understand).
But sometimes quite painful, in the case of a pure stack machine like
the b16. (If you have locals, then it's not really a stack machine).
> It's just that simple: The human is still way more intelligent than the
> machine... Learning to think the Algol way was considerably harder for me
> than learning to think the Forth way.
I don't know that Forth is really much different from Modula-2 at the
semantic level. The benefits of HLL's get more pronounced once the
languages become more expressive. The roman numeral example in Python
is 6 lines without too much golfing:
def roman(n): # assumes 0 < n < 4000
assert 0 < n < 4000
def ro(p,i,v,x):
return ['',i,2*i,3*i,i+v,v,v+i,v+2*i,v+3*i,i+x][p%10]
print ro(n//1000,'m','*','@') + ro(n//100,'c','d','m') \
+ ro(n//10,'x','l','c') + ro(n,'i','v','x')
roman(1234) # prints mccxxxiv
> It's just that simple: The human is still way more intelligent than
> the machine, and can learn to think that way;
Sure, the machine is stupid, but it's extremely fast and accurate and
never gets tired. So, shifting work from the human to the machine is
almost always of benefit to the human.
> So what's the point of moving the communication interface further away
> from both human and machine (the machine is more complicated to
> execute Algol-like languages, and the boilerplate makes it more work
> to program)?
Of course stack machines (or register machines, etc.) are an abstraction
layer over the even deeper language of wires and gates on silicon. The
idea is to get further and further up on the abstraction ladder without
losing sight of what we are doing. This is in part a matter of cultural
progress.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-11-04 16:08 +0200 |
| Message-ID | <70951999928435@frunobulax.edu> |
| In reply to | #17023 |
Paul Rubin <no.email@nospam.invalid> wrote Re: RTX2000 optimization [..] >> ... roman numerals in Forth - this was just one screen, >> i.e. not even 16 lines.... >> The Modula II solution took one page (60 lines), it was by far the >> smallest solution to this exercise ever; the solution from the tutors >> was IIRC 5 pages long. What I had to build manually in Modula II is the >> pictured number buffer, whereas in Forth, I could just use HOLD. [..] > I don't know that Forth is really much different from Modula-2 at the > semantic level. The benefits of HLL's get more pronounced once the > languages become more expressive. The roman numeral example in Python > is 6 lines without too much golfing: > > def roman(n): # assumes 0 < n < 4000 > assert 0 < n < 4000 > def ro(p,i,v,x): > return ['',i,2*i,3*i,i+v,v,v+i,v+2*i,v+3*i,i+x][p%10] > print ro(n//1000,'m','*','@') + ro(n//100,'c','d','m') \ > + ro(n//10,'x','l','c') + ro(n,'i','v','x') > > roman(1234) # prints mccxxxiv > It's just that simple: The human is still way more intelligent than > the machine, and can learn to think that way; The Thinking Forth solution is explicitly written to not duplicate the data. The online version is around 35 lines, so I am really curious how Bernd got less than 16. Also, the online version does not work 'in reverse' and can't use HOLD, so I guess it was reworked. Below is my take. -marcel --- CREATE romans 0 , TEXT% IVXLCDM% : COLUMN CREATE , DOES> @ romans CELL+ + romans ! ; 0 COLUMN ones 2 COLUMN tens 4 COLUMN hundreds 6 COLUMN thousands : <r# ( -- ) PAD C0! ; : r#> ( -- c-addr u ) PAD COUNT ; : rHOLD ( digit -- ) PAD C@+ + C! 1 PAD C+! ; : >SYMBOL ( offset -- ) romans @ + C@ rHOLD ; : ONER 0 >SYMBOL ; : FIVER 1 >SYMBOL ; : TENER 2 >SYMBOL ; : ONERS ( #-of-oners -- ) 0 ?DO ONER LOOP ; : ALMOST ( quotient-of-5 -- ) ONER IF TENER ELSE FIVER ENDIF ; : DIGIT ( digit -- ) 5 /MOD OVER 4 = IF NIP ALMOST EXIT ENDIF IF FIVER ENDIF ONERS ; : ROMAN ( number -- c-addr u ) <r# #1000 /MOD thousands DIGIT #100 /MOD hundreds DIGIT #10 /MOD tens DIGIT ones DIGIT r#> ;
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-11-04 17:14 +0200 |
| Message-ID | <58891899928435@frunobulax.edu> |
| In reply to | #17037 |
mhx@iae.nl (Marcel Hendrix) writes Re: RTX2000 optimization [..] > The online version is around 35 lines, so I am really curious how > Bernd got less than 16. Also, the online version does not work > 'in reverse' and can't use HOLD, so I guess it was reworked. > Below is my take. \ Search online for ," cell[] ( cells +) .$ ( count type) -TO ( negate +TO) \ This won't work for 16bit Forths. : r" align ," align ; CREATE arabics 1 , 4 , 5 , 9 , 10 , 40 , 50 , 90 , 100 , 400 , 500 , 900 , 1000 , CREATE romans r" I" r" IV" r" V" r" IX" r" X" r" XL" r" L" r" XC" r" C" r" CD" r" D" r" CM" r" M" : ROMAN ( n -- ) 0 #12 DO BEGIN DUP arabics I CELL[] @ >= WHILE romans I CELL[] .$ arabics I CELL[] @ - REPEAT -1 +LOOP DROP ; -marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-04 18:40 +0100 |
| Message-ID | <1704327.7k7rYBBJBY@sunwukong.fritz.box> |
| In reply to | #17037 |
Marcel Hendrix wrote: > The online version is around 35 lines, so I am really curious how > Bernd got less than 16. Also, the online version does not work > 'in reverse' and can't use HOLD, so I guess it was reworked. > Below is my take. That was my take on it (the timestamp is my last change to it which was using <<# #> #>> nestable pictured numeric output): \ roman numbers 07aug10py Variable column# : symbol ( off -- ) column# @ + s" IVXLCDM " drop + c@ hold ; : oner ( -- ) 0 symbol ; : fiver ( -- ) 1 symbol ; : almost ( q -- ) 1+ symbol oner ; : oners ( n -- ) 0 ?DO oner LOOP ; : digit ( digit -- ) 5 /mod over 4 = IF almost drop ELSE swap oners IF fiver THEN THEN ; : #r ( digit -- digit' ) 10 /mod swap digit 2 column# +! ; : roman ( number -- ) column# off <<# #r #r #r #r 0 #> type #>> ; This is slightly overfactored, so if you just want to have a low number of lines, it becomes: Variable column# : symbol ( off -- ) column# @ + s" IVXLCDM " drop + c@ hold ; : digit ( digit -- ) 5 /mod over 4 = IF 1+ symbol 0 symbol drop ELSE swap 0 ?DO 0 symbol LOOP IF 1 symbol THEN THEN ; : #r ( digit -- digit' ) 10 /mod swap digit 2 column# +! ; : roman ( number -- ) column# off <<# #r #r #r #r 0 #> type #>> ; -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-04 09:36 -0600 |
| Message-ID | <ZrKdnURioqoNFgvNnZ2dnUVZ8rSdnZ2d@supernews.com> |
| In reply to | #17023 |
Paul Rubin <no.email@nospam.invalid> wrote: > I don't know that Forth is really much different from Modula-2 at the > semantic level. The benefits of HLL's get more pronounced once the > languages become more expressive. The roman numeral example in Python > is 6 lines without too much golfing: > > def roman(n): # assumes 0 < n < 4000 > assert 0 < n < 4000 > def ro(p,i,v,x): > return ['',i,2*i,3*i,i+v,v,v+i,v+2*i,v+3*i,i+x][p%10] > print ro(n//1000,'m','*','@') + ro(n//100,'c','d','m') \ > + ro(n//10,'x','l','c') + ro(n,'i','v','x') > > roman(1234) # prints mccxxxiv But that's kinda nasty: it's doing all that work in '',i,2*i,3*i,i+v,v,v+i,v+2*i,v+3*i,i+x and almost immediately throwing almost all of it away. It'd be a bit different if Python was a lazy evaluator but AFAIK it's not. I'll grant you this is cute, though, and I didn't know about this, er, language feature: Python 2.7.3 (default, Jul 24 2012, 10:05:38) >>> 'm' * 3 'mmm' Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andy Valencia <vandys@vsta.org> |
|---|---|
| Date | 2012-11-04 23:49 +0000 |
| Message-ID | <20121104234704.5748.98261@localhost.localdomain> |
| In reply to | #17023 |
> But that's kinda nasty: it's doing all that work in > '',i,2*i,3*i,i+v,v,v+i,v+2*i,v+3*i,i+x > and almost immediately throwing almost all of it away. It'd be a bit > different if Python was a lazy evaluator but AFAIK it's not. You can do lazy evaluations in Python (using generators), but it would make that source much, much more cumbersome. > I'll grant you this is cute, though, and I didn't know about this, er, > language feature: > Python 2.7.3 (default, Jul 24 2012, 10:05:38) > >>> 'm' * 3 > 'mmm' Most often used in things like [None]*count1 and [0]*count2 to create arrays with a repeated initial contents. Andy
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2012-10-31 12:11 -0700 |
| Message-ID | <54a7ded5-b4a1-4ecd-a025-6a39b7e51487@googlegroups.com> |
| In reply to | #16831 |
On Monday, October 29, 2012 4:02:36 PM UTC-7, Rod Pemberton wrote: > > Are FPGA's required to be clocked? I would've assumed that it's more safe > for the signals to clock, but not a requirement. > Pretty much. Synchronous design is generally assumed. You might be able to build a tool that converts your async CPU design (in your own async design language) to a combination of Verilog/VHDL and timing constraint files for a particular flow. Such a language may already exist as a research project. My impression is that the tools have molded the design process, leaving synchronous design the only practical game in town. The horizontal Novix encoding executes in one clock, making it faster than MISC which executes in several clocks.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-31 20:08 -0400 |
| Message-ID | <k6se9v$gb9$1@speranza.aioe.org> |
| In reply to | #16894 |
"Brad Eckert" <hwfwguy@gmail.com> wrote in message news:54a7ded5-b4a1-4ecd-a025-6a39b7e51487@googlegroups.com... > On Monday, October 29, 2012 4:02:36 PM UTC-7, Rod Pemberton wrote: ... Hey, did anyone ever answer your initial question? The thread has kind of been taken over by rickman... With a list of primitives and the processor instruction set and the processor's stack/register model, an optimal sequences can be designed. I know Alex McDonald is working on an optimizer. I've been using a private, heavily modified version of Peter Sovietov's "Forth Wizard". It's in Javascript and fairly easy to modify, if you know C. The original is here. http://forpost.sourceforge.net/forthwiz.html Koopman's chapter lists some of RTX 2000 instruction set: http://www.ece.cmu.edu/~koopman/stack_computers/sec4_5.html It appears that they are expected Forth sequences, perhaps output from a compiler. I can't see an individual using them ... Based on sequences for various Forth words, I can take guess at how some of them are used: -possibly used for +! like operation DUP @ SWAP -possibly enhanced DROP sequence: DROP nn inv DROP lit inv DROP inv shift nn G@ DROP inv -possibly enhanced DIP sequence: DROP DUP inv shift -possibly enhanced DUP sequence: DUP inv shift DUP lit op DUP nn G@ inv -possibly enhanced OVER sequence: nn OVER op OVER inv shift nn G@ OVER op -possibly enhanced NUP sequence: OVER SWAP op shift OVER SWAP ! inv OVER SWAP ! nn OVER SWAP @ op -possibly enhanced SWAP sequence: lit SWAP inv lit SWAP op nn SWAP op SWAP inv shift nn G@ SWAP op -possibly enhanced NIP sequence: SWAP DROP inv shift SWAP DROP @ nn -possibly enhanced DRIP sequence: SWAP DROP DUP inv shift SWAP DROP DUP @ nn ROT op SWAP DROP DUP @ SWAP -possibly enhanced TUCK sequence: SWAP OVER op shift SWAP OVER ! > > Are FPGA's required to be clocked? I would've assumed that it's more > > safe for the signals to clock, but not a requirement. > > > Pretty much. Synchronous design is generally assumed. You might be able > to build a tool that converts your async CPU design (in your own async > design language) to a combination of Verilog/VHDL and timing constraint > files for a particular flow. Such a language may already exist as a > research project. My impression is that the tools have molded the design > process, leaving synchronous design the only practical game in town. rickman said basically the same thing in one of his replies. What I was trying to get to with rickman, was what I quoted for Andrew: "Rather than totally removing the clock signal, some CPU designs allow certain portions of the device to be asynchronous, such as using asynchronous ALUs in conjunction with superscalar pipelining to achieve some arithmetic performance gains." http://en.wikipedia.org/wiki/Central_processing_unit#Clock_rate I.e., that "one clock" can represent multiple, sequential, internal operations, it doesn't necessarily mean parallel or pipelined. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2012-11-01 10:59 -0700 |
| Message-ID | <cc960a3a-5594-44f8-93ab-e95ffef64f94@googlegroups.com> |
| In reply to | #16919 |
On Wednesday, October 31, 2012 5:04:17 PM UTC-7, Rod Pemberton wrote: > Hey, did anyone ever answer your initial question? The thread has kind of > been taken over by rickman... > It was more an academic question. There are several forth soft cores out there used commercially, but only by their original designers. If it doesn't have a C compiler, nobody's interested. > > http://forpost.sourceforge.net/forthwiz.html > That's a handy little tool, especially for MISC or Shboom style CPUs. I would add a button to copy the stack picture and sequence to the clipboard. > Koopman's chapter lists some of RTX 2000 instruction set: > http://www.ece.cmu.edu/~koopman/stack_computers/sec4_5.html The horizontal encoding style (Novix, J1) is compelling. It needs a better compiler if you want to avoid assembly, but as the J1 showed, using assembly in a really simple processor isn't complex. Besides, portable code isn't as important. It's not like your CPU can be "end-of-life"ed. I think the semantic density of the two encoding styles is comparable.
[toc] | [prev] | [next] | [standalone]
| From | daveyrotten <danw8804@gmail.com> |
|---|---|
| Date | 2012-11-01 12:12 -0700 |
| Message-ID | <cb8a3ad1-ca28-4973-8f02-c572c19ca261@googlegroups.com> |
| In reply to | #16949 |
On Thursday, November 1, 2012 12:59:54 PM UTC-5, Brad Eckert wrote: > > The horizontal encoding style (Novix, J1) is compelling. It needs a better compiler if you want to avoid assembly, but as the J1 showed, using assembly in a really simple processor isn't complex. Besides, portable code isn't as important. It's not like your CPU can be "end-of-life"ed. > I don't understand what you mean. Are you talking about compiling from C or from Forth? What are you considering assembly for the J1? Does the following code use assembly for example? : ! +! drop ; This is how most of my programs for the J1 start. Sorry if this is too pedestrian. I'm just trying to understand. I think much of the problem is getting used to the terms. I'm a hardware guy delving into the software world. Probably that's a dangerous thing. I very much agree with the last statement in your paragraph above, however. That's a big part of what's really cool about simple soft core cpus in FPGAs: obsolesence is really not an issue; at least as long as synthesis from RTL is available in the tools.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web