Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #1242 > unrolled thread
| Started by | gavino <gavcomedy@gmail.com> |
|---|---|
| First post | 2011-04-17 00:34 -0700 |
| Last post | 2011-04-21 18:33 -0700 |
| Articles | 20 on this page of 166 — 22 participants |
Back to article view | Back to comp.lang.forth
made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-17 00:34 -0700
Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-17 02:29 -0700
Re: made it to page 4 of gforth tutorial alberto pasquale <alberto@hal-pc.org> - 2011-04-18 12:55 -0700
Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-18 14:45 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-19 09:06 +0000
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-18 20:30 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-18 20:33 -0700
Re: made it to page 4 of gforth tutorial David Kuehling <dvdkhlng@gmx.de> - 2011-04-19 13:04 +0200
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-19 22:09 +0200
Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-19 23:40 -0700
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-20 21:27 +0200
Re: made it to page 4 of gforth tutorial alberto pasquale <alberto@hal-pc.org> - 2011-04-20 14:56 -0700
Re: made it to page 4 of gforth tutorial stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-20 22:42 +0000
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-20 22:26 -0700
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-21 20:51 +0200
Re: made it to page 4 of gforth tutorial Marc Olschok <nobody@nowhere.invalid> - 2011-04-26 16:40 +0000
Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 22:23 +0200
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 13:34 -0700
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-27 14:48 +0000
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 04:07 -0500
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 07:38 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-21 08:10 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-22 12:35 +0000
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 08:51 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-23 10:17 +0000
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-23 18:05 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 11:16 -0500
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-23 11:26 +0000
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-23 18:07 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 00:10 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 11:38 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 15:13 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 14:07 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:05 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:24 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-22 12:48 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:51 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 17:41 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 18:16 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 18:58 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 19:49 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:02 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-22 06:59 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 01:20 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 21:11 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:16 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:12 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-23 07:38 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:05 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-25 13:34 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 08:50 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:11 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:18 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:19 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 10:43 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-25 13:17 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 16:32 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-25 18:21 -0700
Re: made it to page 4 of gforth tutorial Charles G Montgomery <cgm@physics.utoledo.edu> - 2011-04-26 19:36 -0400
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-26 21:05 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-26 23:36 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-27 08:57 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-28 11:53 +0000
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-29 22:21 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-27 17:41 +0100
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-27 09:53 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-26 11:39 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:22 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-26 17:51 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-23 10:33 +0000
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:48 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-29 22:24 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 09:44 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 11:36 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 17:08 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 18:11 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 00:49 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:55 -0500
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:47 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-23 11:12 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-30 16:33 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:03 -0700
Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-05-02 22:15 +0200
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-02 19:15 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-05-04 08:14 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-04 00:51 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-05-04 22:03 +0100
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-30 03:15 -0500
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-05-01 19:04 -1000
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-27 22:58 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 03:37 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 08:54 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 12:12 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 21:34 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-29 02:27 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-29 15:09 -0700
Re: made it to page 4 of gforth tutorial Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-05-02 21:47 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 10:49 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 21:57 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-05-03 13:28 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 11:01 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:02 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 07:08 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-26 10:47 -0700
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 10:58 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-27 22:39 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 10:43 -0700
Re: made it to page 4 of gforth tutorial David Thompson <dave.thompson2@verizon.net> - 2011-05-05 04:39 -0400
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-05-05 04:10 -0500
Re: made it to page 4 of gforth tutorial stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-23 09:53 +0000
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:59 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-23 16:10 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:47 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-05-03 14:23 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-04 01:48 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-05-04 05:23 -0500
Re: made it to page 4 of gforth tutorial John Passaniti <jpassaniti@ashly.com> - 2011-05-04 11:17 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-05-04 12:03 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:59 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:48 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 03:22 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:28 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 12:37 -0500
Re: made it to page 4 of gforth tutorial David Kuehling <dvdkhlng@gmx.de> - 2011-04-22 20:07 +0200
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-22 18:55 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:25 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-24 03:27 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 20:20 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:24 -0500
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-25 11:55 -1000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:45 -0700
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-25 21:49 -1000
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 02:39 -0700
Re: made it to page 4 of gforth tutorial Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-04-26 03:19 -0700
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:01 +0000
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:43 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:53 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 20:27 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:35 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-26 00:20 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-26 04:02 -0500
Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 22:40 +0200
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-25 14:16 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:25 -0700
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 02:47 -0700
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:22 +0000
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 10:45 -0700
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-26 22:19 +0200
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-27 21:05 +0200
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 11:44 -0700
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-22 11:46 -1000
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-23 08:02 +0100
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:46 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 01:32 -0700
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-24 08:36 -1000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 19:43 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 21:07 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-25 11:04 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:02 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-20 18:17 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:19 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:27 -0700
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-21 16:54 -0700
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-21 17:09 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 17:57 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 18:33 -0700
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-04-28 11:01 -0700 |
| Message-ID | <ace03289-dc4c-458e-baed-08c16f0776d7@e25g2000prf.googlegroups.com> |
| In reply to | #1611 |
On Apr 28, 4:37 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > The 8051 is (was?) a terrific little microcontroller, but > it presents some major challenges to implementors of > high-level languages. Access to memory other than the > 256 bytes of internal RAM is something of an afterthought, > and you can forget anything like a frame pointer. The thing that made the 8051 compelling for many designs was that there were hundreds of derivative parts in the family. There are 8051's that have much larger amounts of RAM (I remember one that offered 8k) and 16-bit memory addressing registers that did things like autoincrement. And they had some that had more efficient instruction execution and (much) higher clock rates. Further, unlike a lot of microcontrollers, the 8051 exposed the address and data bus, so it wasn't uncommon to add external SRAM and ROM. And most every C compiler for the 8051 I ever used offered support for banked SRAM and ROM. I used that a couple times in projects where there was very strong resistance to changing the processor. And yes, the chip was pretty hostile to just about every language. But for the programmer, you could mostly forget about this. Yeah, when you looked at the assembly code generated, you got depressed, but most of the time, you're operating above that level. > For that reason, statically allocating local variables > makes perfect sense. Getting Forth to work well on the > 8051 is a difficult job. And it *still* makes sense, on both other 8-bit systems and even on larger ones. For one, it gives you *exactly* the amount of RAM used by your functions, so there is no guesswork or manual inspection to figure that out. And because the RAM used for parameters and locals is at fixed locations, the compiler can generate more efficient code-- since the variables aren't relative to some stack frame. So code is a bit faster.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-04-23 14:02 -0700 |
| Message-ID | <3a840d60-57d9-442f-a3df-c47add0189b9@j16g2000pro.googlegroups.com> |
| In reply to | #1446 |
On Apr 23, 3:49 am, Paul Rubin <no.em...@nospam.invalid> wrote: > Wait, what kind of C compiler is that? I thought even very > small cpus these days tended to use GCC. I'd certainly call > a compiler that did what you describe something other than > a C compiler. Thanks for being an illustration of the kind of people I was talking about in my message to Jeff: Programmers who only know C in non- embedded contexts, or who have a limited exposure to the range of run- time implementation strategies that C compilers take. Here's a short thought experiment for you: Say I create a Forth compiler that doesn't have a data stack at all. There isn't even a data stack pointer. Instead, I use the processor's registers and dataflow analysis to write code that produces semantically equivalent actions. To the programmer, they still push, pop, and juggle the stack as before-- zero changes to their code. But under the covers, there isn't actually a stack. So my question to you is if the resulting system would still be called a Forth. The C compilers that use the "compiled stack" technique do much the same thing. Instead of creating a stack frame for parameters and locals, the linker uses a call graph to allocate those parameters and locals statically, overlaying variables that aren't active at the same time. To the C programmer, they still pass parameters and use locals as before-- zero changes to their code. The call/return semantics are exactly the same, except that you can't have recursive (or more generally, reenterant functions). But on small microcontrollers, recursion isn't often used. And if for some reason you really need to make your 8051 with 128 bytes of RAM calculate Ackerman functions, you usually can tell the compiler and linker to treat the function more traditionally and just those functions will allow recursion. So why exactly would you consider a C compiler that generated semantically equivalent code to be something other than a C compiler? Because if it doesn't match a run-time implementation strategy you're familiar with? The embedded world is much larger than GCC. There are many compiler vendors who found out years ago that the code generation strategies for larger processors simply don't make sense for smaller microcontrollers. For example, it's very common for embedded C compilers to offer specialized memory models to take advantage of faster addressing modes the microcontroller offers, and to not offer float support unless you explicitly ask for it (Forth isn't the only language that traditionally avoided floats and used fixed point-- embedded C programmers have been doing this as well for years, avoiding the cost of either floating point hardware or run-time library support). Most of these compilers assume that doubles are floats, and do things like not automatically expand expressions that use chars and shorts to ints when there is no value in doing so. And very commonly, many of these C compilers will do things like require ANSI prototypes and use that information so that when calling a function expecting a char argument, it won't be coerced into an int. And so on. C programmers love convenience functions like printf. But how do you printf to standard output when there isn't an operating system on the target? Every C compiler for embedded systems I've ever seen does so by having the programmer define the C equivalent of Forth's EMIT and KEY. You set up your output device, write a function to spit characters at it, and presto, printf works. And functions in the printf/scanf family also reflect this by usually offering different versions that you select at link time-- usually a version that doesn't do fancy formatting, a version that doesn't do floats, and a version that has all features. There are vast numbers of microcontrollers that have zero support in GCC. I see no support in GCC for the popular Freescale HC(S)08 family, nor do I see it for ancient 8-bit processors (like the 8051, 6502, and Z80) that these days are more commonly seen as soft cores in FPGAs. That's also very true of the many odd 16-bit microcontrollers out there. And even when there is a GCC available for more common 32- bit microcontrollers (such as ARM and ColdFire), there are other compiler vendors that often generate better code because they don't have to conform to a ABI for an operating system that isn't there. Most of the systems I work on these days are ColdFire-based, and although GCC supports that, the Metrowerks compiler generates better (smaller, faster) code. I've mentioned a few of the vendors before, but repeating, Metrowerks, Keil, IAR, ImageCraft, Tasking, Avocet, and many others I'm probably forgetting I've used over the years. Getting back to the larger point here, many times in comp.lang.forth, there is a weird apples/oranges comparison going on between Forth targeting embedded systems and C targeting non-embedded systems. We have Forth people here (Jeff Fox being the most notorious) who constantly use examples of C in non-embedded contexts to show how C isn't good for embedded contexts. And we have people like you-- I don't know your experience level with C, but it certainly doesn't include using C in embedded systems. Or if it is, it's only on embedded systems that are large enough to host desktop operating systems. What both you and Jeff illustrate is that there are indeed C programmers out there-- possibly even highly skilled ones-- who if they had to target a small, resource-constrained embedded system, would have a very hard time wrapping their brains around them. These are systems that might only have a couple hundred bytes of RAM and not much more ROM and require very different ways of thinking about writing code, if one wants to write in C. And so if you ask these people what kind of resources they would want to see on a chip like those designed by Charles Moore, OF COURSE they are going to just toss their hands up the in the air and say it's impossible. But for me, and the many other software engineers who have been targeting these systems for years now, we know better. When I look at the GreenArrays chip for example, I have absolutely no problem imagining bringing C to it. If I remember correctly, the only way you saw that happening was to implement a virtual machine. I don't see any such need. The very same execution strategies that C compilers for smaller microcontrollers use today would apply just fine to an even more resource-constrained system like in the GreenArrays chips. Now, I personally don't think that would be a terribly great idea and that ArrayForth makes a lot more sense for the GreenArrays chips. But I can easily see how someone could take an existing compiler framework (like LCC, which is far simpler than GCC) and generate code that ran directly on nodes of the GreenArrays chip. Like ArrayForth, I wouldn't rely on the compiler to work out the floor-planning aspect of code generation; the programmer would best design that and specify with #pragma's. I don't think that without very aggressive optimization of the code that you would get the same code density of hand-tuned ArrayForth, but hey, when you have that many processors on a chip that are running that fast, you might be able to afford a few extra instructions here and there. Again, not ideal-- ArrayForth would be ideal-- but software engineering is often less about the ideal and more about the practical and pragmatic.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-25 07:08 -0700 |
| Message-ID | <7x62q277aa.fsf@ruckus.brouhaha.com> |
| In reply to | #1470 |
John Passaniti <john.passaniti@gmail.com> writes:
> So why exactly would you consider a C compiler that generated
> semantically equivalent code to be something other than a C compiler?
> Because if it doesn't match a run-time implementation strategy you're
> familiar with?
You wrote in earlier message:
It obviously prevents the ability to create recursive calls to a
function (except for tail recursion which can always be replaced
with iteration).
That sounded like you were decribing a compiler that doesn't support
recursion other than tail recursion, i.e. doesn't follow the C standard.
The usual hack of printing decimal numbers using recursion wouldn't
work, for example. So I'd have trouble calling that a C compiler.
> The embedded world is much larger than GCC. ... For example... and to
> not offer float support unless you explicitly ask for it...
GCC supports that kind of stuff, I thought.
> Most of these compilers assume that doubles are floats,
Wait, I explicitly ask for a double and get a single? That seems pretty
bogus.
> functions in the printf/scanf family also reflect this by usually
> offering different versions that you select at link time-...
Sure, that's reasonable for the library, nothing to do with the
compiler.
> I see no support in GCC for the popular Freescale HC(S)08 family, nor
> do I see it for ancient 8-bit processors (like the 8051, 6502, and
> Z80) that these days are more commonly seen as soft cores in FPGAs.
Oh that's interesting, I thought the 8051 was supported and I know
the AVR8 is supported. I wasn't thinking about the 6502 and Z80.
> And we have people like you-- I
> don't know your experience level with C, but it certainly doesn't
> include using C in embedded systems.
Tons of non-embedded C, a fair amount of 32-bit embedded, and (as you
guessed) no tiny embedded to speak of. I've been interested in the AVR8
for some things (that's also what originally brought me to c.l.f.) and
the main toolchain I know of for it uses GCC.
> When I look at the GreenArrays chip for example, I have absolutely no
> problem imagining bringing C to it. If I remember correctly, the only
> way you saw that happening was to implement a virtual machine.
Well, the VM suggestion was from Greg Bailey, the president of GA, who I
figure knows what he's talking about. He talks about it in his recent
Forth Day video on forth.org, and in fact he more or less pleads for
someone to do it. (I've put a little thought into it but realistically
have too many other things to pursue). I figured its purpose was to
allow writing the outer control and UI layer of the user application
using a traditional, relaxed style of C programming rather than a memory
starved one. GA uses Eforth the same way now--there is a VM for it
programmed into the ROM of the GA144. I spent a few minutes looking at
the VM code to see if it also seemed suitable for C, but it looks like
it would take some head scratching to figure out what it actually does.
> But I can easily see how someone could take an existing compiler
> framework (like LCC, which is far simpler than GCC) and generate code
> that ran directly on nodes of the GreenArrays chip.
Yeah, I've toyed with the idea of a Haskell EDSL targeted at the GA
nodes, that would attempt whole-program optimization and also give
some compile-time safety checking that couldn't really be done in C.
> without very aggressive optimization of the code that you would get
> the same code density of hand-tuned ArrayForth, but hey, when you have
> that many processors on a chip that are running that fast, you might
> be able to afford a few extra instructions here and there.
I'd expect the overriding constraint is the limited code space available
in each node. Using more nodes would seem to create a lot of
communications requirements that would in turn need even more code to
deal with, etc. This is why I was asking about diagonal ports so each
node would have 8 neighbors, allowing avoiding some routing of data
around nodes that were in use for other things.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-04-26 10:47 -0700 |
| Message-ID | <6367f443-6293-46ec-b246-440c9f72868b@q12g2000prb.googlegroups.com> |
| In reply to | #1512 |
On Apr 25, 10:08 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> That sounded like you were decribing a compiler that doesn't
> support recursion other than tail recursion, i.e. doesn't
> follow the C standard. The usual hack of printing decimal
> numbers using recursion wouldn't work, for example. So I'd
> have trouble calling that a C compiler.
The ANSI and ISO C standards only state that recursive function calls
"shall be permitted." Neither standard specifies (or ever could
specify!) the /limits/ of such recursive calls-- how many recursive
calls are allowed; the maximum amount of additional allocation per
invocation. That's solely up to the compiler vendor and the end
programmer to define, based on the availability of resources. If that
wasn't the case-- if the ANSI or ISO C standards did mandate that N
bytes of RAM be reserved for recursive calls-- then you would have a
hell of a lot of resource-constrained platforms that couldn't run C
not because of any technical limitation, but because of requirements
imposed by language lawyers.
The "usual hack" of printing decimal numbers is I assume some
variation on this:
void printnum(unsigned int n) {
if (n > 0)
printnum(n/10);
putchar('0' + n % 10);
}
Elegant... and stupidly expensive in both RAM and processor cycles.
On a typical 8-bit system, you'll have 16-bit integers and 16-bit
addresses. The worst case then would be a five-digit number, with one
recursive call per digit and one integer parameter. That's 20 bytes
of stack wasted to print a number. Or put more practically, taking an
old-school 8051, that's about 16% of the processor's RAM-- and that's
assuming you used zero RAM for your actual application. If a
programmer working under me submitted that code, it would be flagged
in a code review and they would be asked to rewrite it using
iteration.
Rule number one for any embedded system programmer is to "respect the
target." Your "usual hack" is saying, "I have no interest in the
specifics of the target, I'm going to pretend that I can do anything I
can do on any other platform that supports C."
So no, although you may love this "usual hack," it's not something any
experience embedded systems programmer-- regardless of language--
would execute on a resource-constrained system. This is in fact the
kind of thing that is a big blinking neon sign over the head of the
programmer that says "I am unfamiliar with how to write code
appropriate for platforms such as this."
More importantly, a system that uses "compiled stack" which imposes
limits on recursion is not in any way diminished by your inability to
do things that are inappropriate for the platform.
But rest assured-- on every system I've seen that offers "compiled
stack", there is a way to revert to more traditional code generation
strategies and/or to selectively choose specific functions that will
fully support recursion.
> > Most of these compilers assume that doubles are floats,
>
> Wait, I explicitly ask for a double and get a single?
> That seems pretty bogus.
You keep losing context-- C compilers microcontrollers in embedded
systems. Nearly universally, there is no floating point hardware, so
your application gets linked with floating point support libraries.
And again, memory is precious, so you don't waste it with more
precision than you need. More to the point, if you are using reals,
you are more than likely also using a routine in math.h, and if you
look at the prototypes, nearly every one of them accepts one or more
doubles (implying float arguments would be widened to doubles) and
nearly everyone returns a double (implying a down-cast and loss of
precision). That's hugely wasteful in both RAM and processor cycles
on embedded targets, so by having a compiler option that says "doubles
are floats" the programmer can make choices between precision and
resource usage.
The larger point here is what I told Jeff: You can take someone who
is very experienced with C, but who isn't experienced with C on
resource-constrained embedded systems. And if you ask that person
what requirements the target platform must provide in order to support
C, they are going to take their experience and expectations. But if
you take someone who has used the C compilers that are specifically
designed around the resource limitations and the actual kind of code
programmers write for microcontrollers in embedded systems, then
you'll get a very different answer.
You (and Jeff, and others) are basing expectations of what the target
platform must provide from experience on larger systems. Trying to
translate that down to a chip like the GA144 doesn't make any sense,
but because you haven't seen the kind of design decisions and
implementation strategies used in the C compilers I'm talking about,
you don't see those options.
> Well, the VM suggestion was from Greg Bailey, the
> president of GA, who I figure knows what he's
> talking about.
Yes, creating a virtual machine is one way to bring C (and other
languages) to the GA144. The obvious advantage being that one can
design and optimize the virtual machine for the language, and one can
run much larger programs than one could on any individual processor.
But because I have experience with code generation strategies for
small processors, I can see an alternate model, where code is
generated for each processor. Obviously, the code for each processor
is much more limited and would serve a different purpose. Targeting a
virtual machine is the kind of thing I would do for larger code that
didn't need to run at insanely fast speeds, such as user interfaces,
Ethernet network stacks, and stuff like that. Targeting the
processors themselves would be more for signal processing,
implementing hardware, etc.
One's reaction to that statement will vary based on one's experience
actually using C compilers that generate code for smaller targets.
For example, Jeff Fox once asked in comp.lang.forth how many bytes a C
compiler would generate for a simple "Hello, World" application or
somesuch. His frame of reference was desktop and server operating
systems, where even a putchar call would result in a huge stack of
code from the application to support libraries to operating system to
device drivers to BIOS. He said one needed to add up all that code
and that was the total cost. And... he's mostly right. He failed to
amortize the cost of code that is reused, but that's not something
Jeff understands.
Regardless, I don't remember the number I quoted for the embedded C
compiler I had in front of me, but it was a small number-- around 200
bytes. And the vast majority of that was just standard boilerplate
code that initialized memory, set up the microcontroller's clock and
UART, and branched to main, which was a call to puts instead of the
canonical (and wasteful) printf. And if one didn't care about that
standard-conforming startup code, one could have gotten the whole
thing down to less than around 64 bytes or so.
The point isn't a stupid benchmark war over "Hello, World" programs.
The point is that someone without the frame of reference that I and
other embedded software engineers have targeting these kinds of
systems, a number like 200 bytes or less is unimaginable. And now
translating to the GA144, I'm sure there are people who think it would
be insane to even attempt to target a C for each processor. But
that's because they don't know what is possible.
Years ago, with an older version of LCC, I read enough of the
documentation and code so that I could create a back-end that I used
for program analysis (instead of generating code, I generated a
database of statistics related to the code). I have in mind a fun
little side project where I get up to speed on the latest in LCC and
see the quality of code I could generate from a back-end targeting the
GA144 directly. As I wrote before, I have absolutely no illusion that
such code would seriously compete with hand-tuned Forth. But I am
interested in exactly how far away it would be from that ideal.
Instead of Jeff tossing his usual unsubstantiated random powers-of-ten
arguments around, I'd like an actual measurement.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-04-26 10:58 -0700 |
| Message-ID | <03bcb932-7eff-4ee1-9895-e75a3142e46b@p16g2000vbi.googlegroups.com> |
| In reply to | #1554 |
On Apr 26, 6:47 pm, John Passaniti <john.passan...@gmail.com> wrote:
> On Apr 25, 10:08 am, Paul Rubin <no.em...@nospam.invalid> wrote:
>
> > That sounded like you were decribing a compiler that doesn't
> > support recursion other than tail recursion, i.e. doesn't
> > follow the C standard. The usual hack of printing decimal
> > numbers using recursion wouldn't work, for example. So I'd
> > have trouble calling that a C compiler.
>
> The ANSI and ISO C standards only state that recursive function calls
> "shall be permitted." Neither standard specifies (or ever could
> specify!) the /limits/ of such recursive calls-- how many recursive
> calls are allowed; the maximum amount of additional allocation per
> invocation. That's solely up to the compiler vendor and the end
> programmer to define, based on the availability of resources. If that
> wasn't the case-- if the ANSI or ISO C standards did mandate that N
> bytes of RAM be reserved for recursive calls-- then you would have a
> hell of a lot of resource-constrained platforms that couldn't run C
> not because of any technical limitation, but because of requirements
> imposed by language lawyers.
>
> The "usual hack" of printing decimal numbers is I assume some
> variation on this:
>
> void printnum(unsigned int n) {
> if (n > 0)
> printnum(n/10);
> putchar('0' + n % 10);
>
> }
>
> Elegant... and stupidly expensive in both RAM and processor cycles.
> On a typical 8-bit system, you'll have 16-bit integers and 16-bit
> addresses. The worst case then would be a five-digit number, with one
> recursive call per digit and one integer parameter. That's 20 bytes
> of stack wasted to print a number. Or put more practically, taking an
> old-school 8051, that's about 16% of the processor's RAM-- and that's
> assuming you used zero RAM for your actual application. If a
> programmer working under me submitted that code, it would be flagged
> in a code review and they would be asked to rewrite it using
> iteration.
>
> Rule number one for any embedded system programmer is to "respect the
> target." Your "usual hack" is saying, "I have no interest in the
> specifics of the target, I'm going to pretend that I can do anything I
> can do on any other platform that supports C."
>
> So no, although you may love this "usual hack," it's not something any
> experience embedded systems programmer-- regardless of language--
> would execute on a resource-constrained system. This is in fact the
> kind of thing that is a big blinking neon sign over the head of the
> programmer that says "I am unfamiliar with how to write code
> appropriate for platforms such as this."
>
> More importantly, a system that uses "compiled stack" which imposes
> limits on recursion is not in any way diminished by your inability to
> do things that are inappropriate for the platform.
>
> But rest assured-- on every system I've seen that offers "compiled
> stack", there is a way to revert to more traditional code generation
> strategies and/or to selectively choose specific functions that will
> fully support recursion.
>
> > > Most of these compilers assume that doubles are floats,
>
> > Wait, I explicitly ask for a double and get a single?
> > That seems pretty bogus.
>
> You keep losing context-- C compilers microcontrollers in embedded
> systems. Nearly universally, there is no floating point hardware, so
> your application gets linked with floating point support libraries.
> And again, memory is precious, so you don't waste it with more
> precision than you need. More to the point, if you are using reals,
> you are more than likely also using a routine in math.h, and if you
> look at the prototypes, nearly every one of them accepts one or more
> doubles (implying float arguments would be widened to doubles) and
> nearly everyone returns a double (implying a down-cast and loss of
> precision). That's hugely wasteful in both RAM and processor cycles
> on embedded targets, so by having a compiler option that says "doubles
> are floats" the programmer can make choices between precision and
> resource usage.
>
> The larger point here is what I told Jeff: You can take someone who
> is very experienced with C, but who isn't experienced with C on
> resource-constrained embedded systems. And if you ask that person
> what requirements the target platform must provide in order to support
> C, they are going to take their experience and expectations. But if
> you take someone who has used the C compilers that are specifically
> designed around the resource limitations and the actual kind of code
> programmers write for microcontrollers in embedded systems, then
> you'll get a very different answer.
>
> You (and Jeff, and others) are basing expectations of what the target
> platform must provide from experience on larger systems. Trying to
> translate that down to a chip like the GA144 doesn't make any sense,
> but because you haven't seen the kind of design decisions and
> implementation strategies used in the C compilers I'm talking about,
> you don't see those options.
>
> > Well, the VM suggestion was from Greg Bailey, the
> > president of GA, who I figure knows what he's
> > talking about.
>
> Yes, creating a virtual machine is one way to bring C (and other
> languages) to the GA144. The obvious advantage being that one can
> design and optimize the virtual machine for the language, and one can
> run much larger programs than one could on any individual processor.
>
> But because I have experience with code generation strategies for
> small processors, I can see an alternate model, where code is
> generated for each processor. Obviously, the code for each processor
> is much more limited and would serve a different purpose. Targeting a
> virtual machine is the kind of thing I would do for larger code that
> didn't need to run at insanely fast speeds, such as user interfaces,
> Ethernet network stacks, and stuff like that. Targeting the
> processors themselves would be more for signal processing,
> implementing hardware, etc.
>
> One's reaction to that statement will vary based on one's experience
> actually using C compilers that generate code for smaller targets.
> For example, Jeff Fox once asked in comp.lang.forth how many bytes a C
> compiler would generate for a simple "Hello, World" application or
> somesuch. His frame of reference was desktop and server operating
> systems, where even a putchar call would result in a huge stack of
> code from the application to support libraries to operating system to
> device drivers to BIOS. He said one needed to add up all that code
> and that was the total cost. And... he's mostly right. He failed to
> amortize the cost of code that is reused, but that's not something
> Jeff understands.
>
> Regardless, I don't remember the number I quoted for the embedded C
> compiler I had in front of me, but it was a small number-- around 200
> bytes. And the vast majority of that was just standard boilerplate
> code that initialized memory, set up the microcontroller's clock and
> UART, and branched to main, which was a call to puts instead of the
> canonical (and wasteful) printf. And if one didn't care about that
> standard-conforming startup code, one could have gotten the whole
> thing down to less than around 64 bytes or so.
>
> The point isn't a stupid benchmark war over "Hello, World" programs.
> The point is that someone without the frame of reference that I and
> other embedded software engineers have targeting these kinds of
> systems, a number like 200 bytes or less is unimaginable. And now
> translating to the GA144, I'm sure there are people who think it would
> be insane to even attempt to target a C for each processor. But
> that's because they don't know what is possible.
>
> Years ago, with an older version of LCC, I read enough of the
> documentation and code so that I could create a back-end that I used
> for program analysis (instead of generating code, I generated a
> database of statistics related to the code). I have in mind a fun
> little side project where I get up to speed on the latest in LCC and
> see the quality of code I could generate from a back-end targeting the
> GA144 directly. As I wrote before, I have absolutely no illusion that
> such code would seriously compete with hand-tuned Forth. But I am
> interested in exactly how far away it would be from that ideal.
> Instead of Jeff tossing his usual unsubstantiated random powers-of-ten
> arguments around, I'd like an actual measurement.
You might want (and you may well have already) to look at LLVM; it
appears at first blush to be a little easier than LCC to produce a
back-end such as you describe. I've tinkered with it for use in Forth,
but haven't pursued it very far due to the limited calling conventions
supported; Haskell is about as "far out" as it gets from standard C.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-27 22:39 -0700 |
| Message-ID | <7xmxjb9bot.fsf@ruckus.brouhaha.com> |
| In reply to | #1554 |
John Passaniti <john.passaniti@gmail.com> writes: > Elegant... and stupidly expensive in both RAM and processor cycles... > That's 20 bytes of stack wasted to print a number. Well, "wasted" implies that you don't get it back when the function returns, which you do. More relevant is whether some other path in the application uses even more stack depth, in which case you have to reserve the stack space anyway. Keep in mind also that the most likely reason to encounter this code is it's inside code you're porting from some other project or product. That means if you rewrite it, in addition to the programming/testing/process effort of "fixing" something that is already tested and working, you now have an unnecessary fork point in your code base, something that requires some level of justification beyond "stupidly expensive". (Does anyone use 128-byte 8051's any more anyway?) Remember too that the iterative version will probably use a pointer variable (2 bytes) and an in-memory buffer (5 bytes), so the recursive version maybe only uses 12-13 more bytes, not 20. And of course the iterative version can be done pretty badly too: look at http://www.cpm.z80.de/small_c.html, extract the http://www.cpm.z80.de/small_c/smc88dos.zip (small C for 8088) zip file, look at itoa.c and the layers of crap it calls, and weep. Its stack consumption looks like more than 20 bytes when you count everything. As for CPU cycles, the i/o and the division by 10 may dominate the stack operations either way. > If a programmer working under me submitted that code, it would be > flagged in a code review and they would be asked to rewrite it using > iteration. And if you invoiced me for such a rewrite of working and already-deployed code, without concrete justification (product functionality visibly improved by having the extra few bytes available), I'd be concerned that you were wasting my money ;-). It seemed like just a minute ago you were saying "for many the goal is less about optimality and more about pragmatism"[1] but now you're writing these creeds about a dozen bytes in a print function. Really, I'd expect the compiler library to already have a decimal print function (probably written in assembler in a small-platform implementation) so if the recursive function gets replaced at all, it should be to the library routine rather than a newly written function. > Rule number one for any embedded system programmer is to "respect the > target." You mean it's not "ship the product"? ;-) > Your "usual hack" is saying, "I have no interest in the > specifics of the target, I'm going to pretend that I can do anything I > can do on any other platform that supports C." You mean like port existing code? > This is in fact the kind of thing that is a big blinking neon sign > over the head of the programmer that says "I am unfamiliar with how to > write code appropriate for platforms such as this." Really, for writing new code on such a platform, if you're really concerned about resources, C is just a terrible language, though it sounds like you're already halfway to turning it into "C-like" for the sake of getting around those issues. You're better off with a language more suitable for the architecture. > Nearly universally, there is no floating point hardware, so your > application gets linked with floating point support libraries. And > again, memory is precious, so you don't waste it with more precision > than you need. Right, that's why float and double are two separate types, and you don't ask for a double unless you need one. > More to the point, if you are using reals, you are > more than likely also using a routine in math.h, and if you look at > the prototypes, nearly every one of them accepts one or more doubles The version I'm looking at (glibc's) is conditionalized to use doubles or floats. Andrew would know more about it, but IIRC the C standards folks put some effort into getting stuff straightened out in C99 so you don't get doubles when you only want floats. > Yes, creating a virtual machine is one way to bring C (and other > languages) to the GA144. The obvious advantage being that one can > design and optimize the virtual machine for the language, and one can > run much larger programs than one could on any individual processor. Right, that's the idea, to run big programs and existing code. On the GA node itself, I don't see much point to trying to write in C, since with only 64 words of program memory, writing in assembler (i.e. Array Forth) is not much of a roadblock, and there's no useful existing C code to port anyway. From what I can tell you really do have to program those things at quite a low level, carefully managing the partitioning and interaction between nodes. You can't just plop nodes down like bricks based on the amount of resources you need. So the request for a C compiler targeted to a VM is like suggesting a softcore processor that runs C for an FPGA. > Targeting a virtual machine is the kind of thing I would do for larger > code that didn't need to run at insanely fast speeds, such as user > interfaces, Ethernet network stacks, and stuff like that. Yes, that is the idea. > Targeting the processors themselves would be more for signal > processing, implementing hardware, etc. If you want a HLL for that, C just seems like a terrible choice. Better to concoct some DSL that carefully tracks the stack content, has interprocedural optimization, knows about inter-node communication, etc. > Years ago, with an older version of LCC, Be aware that LCC isn't free except for personal use. It's partly a matter of background and preference but I'd be more likely to start with something like Atom: http://hackage.haskell.org/package/atom I've fooled with it some, and it is pretty simple to extend if you know Haskell. The same guy has something called ImProve that also looks interesting: https://github.com/tomahawkins/improve/wiki/ImProve [1] http://groups.google.com/group/comp.lang.forth/msg/3ac101648a3c4cec
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-04-28 10:43 -0700 |
| Message-ID | <b57b2d9f-9464-47db-980e-973b4aeda6fd@z13g2000yqg.googlegroups.com> |
| In reply to | #1607 |
On Apr 28, 1:39 am, Paul Rubin <no.em...@nospam.invalid> wrote: > Well, "wasted" implies that you don't get it back when > the function returns, which you do. More relevant is > whether some other path in the application uses even > more stack depth, in which case you have to reserve > the stack space anyway. Yes, and in any non-trivial program, you're likely to have interrupts as well. So yes, it is wasted space that cuts into not only your application space, but reduces your margins for servicing interrupts. On a classic 8051, you have 128 bytes of internal RAM, and that is used for application variables and stack. So again, someone targeting that (or similar) is going to care very much about how much RAM (not just stack) space is used. > Keep in mind also that the most likely reason to > encounter this code is it's inside code you're > porting from some other project or product. And this again is an example of someone taking a desktop/server mindset in C and applying it to embedded systems. No serious embedded systems programmer is going to mindlessly take code written for larger platforms and drop it in. And if they do, they deserve what they get. One certainly can expect code that was written for other projects that *also* used the same processor or that was written with an awareness of this class of processor to be reused as-is. I've done that often. And there are clearly going to be some platform independent routines here and there which can reliably reused. But I'm still going to read every last bytes of source code and *think* about if that code will cause problems, either because of limited resources or other limitations of the platform. > That means if you rewrite it, in addition to the > programming/testing/process effort of "fixing" > something that is already tested and working, you > now have an unnecessary fork point in your code > base, something that requires some level of > justification beyond "stupidly expensive". A reduction of the margins available for both application RAM and ISRs is plenty reason enough to justify that. You're seriously going to tell me that "testing and working" is a justification for using an unnecessary technique that you referred to as a hack? Sorry, but welcome to 2011 where modern agile software development methodologies are focused more on what is right than the false economy of reusing code that is wasteful. > (Does anyone use 128-byte 8051's any more anyway?) Yes. Hard as it may be to believe, the 8051 (and other older processors) live on. This is a constant thorn in the side of people who don't understand these architectures, and you often see (even in comp.lang.forth) amazement that not everyone is dedicating 32-bit processors to drive front-panel LEDs and read switches. In the real world, costs matter. But sometimes even more than cost what matters is what is appropriate and necessary. Most modern 8051 variants typically have more RAM, but still never much. And even when we're not talking about a physical 8051, we're often talking about synthesized 8051's implemented in FPGAs as control processors. The advantages are obvious-- the 8051 has a long and rich history and there are many programmers who understand them very well. So if you need a control processor in a FPGA, an 8051 is a reasonable choice. > Remember too that the iterative version will probably > use a pointer variable (2 bytes) and an in-memory > buffer (5 bytes), so the recursive version maybe only > uses 12-13 more bytes, not 20. Written like someone who has never had to face running out of RAM. > And of course the iterative version can be done pretty > badly too: look at [...] No, I don't need to see illustrations of bad code that I wouldn't use in my own system. Again, shocking as it may be to believe, as an engineer, I'm responsible for every last byte in the systems I design, so I'm not going to mindlessly accept code someone else wrote. For example, I have only used the provided printf-family of functions that came with an embedded C compiler once. Every other time, I've looked at the code, found it had functionality I didn't need or want, and rewrote my own with a focus on efficiency. Even on a larger 32-bit platform I recently wrote code for, I found the smallest system- provided printf-family routines bloated my code by like 15k. My version, which does exactly what I need it to do, is 1.5k. > > If a programmer working under me submitted that code, > > it would be flagged in a code review and they would > > be asked to rewrite it using iteration. > > And if you invoiced me for such a rewrite of working > and already-deployed code, without concrete justification > (product functionality visibly improved by having the > extra few bytes available), I'd be concerned that you > were wasting my money ;-). Hidden in there is that the "few bytes" are meaningless. They aren't. In this scenario, you hired me not because I'm someone (like you) who has generic C experience. You hired me because I've been doing this for 23ish years now and I have a very good sense of what is and isn't justified. The luxury you have of taking a simple example of a "usual hack" that you apparently love is that you're not considering the entire system and the effect of that code on the system. I've seen the effects of the kind of false economy you promote before, and part of my career has been cleaning up the messes left behind from people who say, "well gosh, it's just a few bytes or cycles here and there." Take that attitude and scale it up to an entire system and suddenly, you're respinning a new board with a bigger, faster processor. And as the NRE on a project rises, as timelines slip, and as products don't get produced, these people scratch their heads and wonder what the problem is. > It seemed like just a minute ago you were saying "for many > the goal is less about optimality and more about > pragmatism"[1] but now you're writing these creeds about > a dozen bytes in a print function. Context matters. > Really, I'd expect the compiler library to already have > a decimal print function (probably written in assembler > in a small-platform implementation) so if the recursive > function gets replaced at all, it should be to the > library routine rather than a newly written function. The reality you would quickly find if you did start working on embedded systems of this class is that rule one "trust but verify." Like anyone else, I'll gladly use a library routine, but I will always examine it to see if it is wasteful. This was a lesson I learned very early in my career. Like a lot of people experienced with C, I just went ahead an used library functions without review. Indeed, some compiler vendors charge extra for the library source code, and at the time, I thought it was a wasted expense. That changed when I later found out that some functions I used were horrifically inefficient, and it was affecting operations. > > Rule number one for any embedded system programmer > > is to "respect the target." > > You mean it's not "ship the product"? ;-) Written like my predecessor where I work now, who literally put time to market before *everything*. And for the past year, most of my work has been cleaning up the messes he left behind. "Ship the product" doesn't mean much if you ship shit and two months later your Support department is swamped in service calls. One of the key skills I've learned over the years as a software engineer is to when to say, "sorry, you can't ship this yet." The pressure can be enormous, and I've more than once been in the situation where there has been a million dollars of parts on a loading dock waiting for final software. But if that becomes your priority, it becomes another false economy as customers are driven away. > > Your "usual hack" is saying, "I have no interest in the > > specifics of the target, I'm going to pretend that I can > > do anything I can do on any other platform that supports C." > > You mean like port existing code? There is a difference between porting existing code written for a system that isn't resource-constrained to one that is. In my experience, writing code that is efficient in the first place and that doesn't needlessly use techniques (like recursion) when it isn't necessary is the solution is the key to portability. The larger context of this entire discussion are small, very resource- constrained platforms like the GA144. And so no, if you think you're going to mindlessly take code written for systems that have megabytes and memory and port them to the GA144 without careful consideration of what you're doing, then sorry, it isn't going to work. > > This is in fact the kind of thing that is a big blinking > > neon sign over the head of the programmer that says "I > > am unfamiliar with how to write code appropriate for > > platforms such as this." > > Really, for writing new code on such a platform, if you're > really concerned about resources, C is just a terrible > language, though it sounds like you're already halfway to > turning it into "C-like" for the sake of getting around > those issues. You're better off with a language more > suitable for the architecture. C is a fine language when used intelligently and most of the compilers I'm talking about generate very high-quality code. The problem is that some people (apparently you included) don't want to use it intelligently. They want to pretend that they can ignore the underlying platform. I still find amusing that you have a problem with a C compiler that offers the ability to generate more efficient code by restricting a programming technique that isn't used often in embedded systems. And like I've written before, if one *really* needs recursion (as I have, such as to deal with tree and other recursive data structures), then you're free to selectively mark specific functions as allowing recursion, or turn off the "compiled stack" optimization entirely. But if you're not using recursion, why in the world would you force a code generation strategy on a compiler that when you don't need it? That's just bizarre. > Right, that's why float and double are two separate types, > and you don't ask for a double unless you need one. And yet, people do. People who don't understand floating point operations often mindlessly put in "double" when it isn't necessary. And given the importance you seem to put on mindlessly porting existing code, having unnecessary doubles can be a problem. > The version I'm looking at (glibc's) is conditionalized > to use doubles or floats. Andrew would know more about > it, but IIRC the C standards folks put some effort into > getting stuff straightened out in C99 so you don't get > doubles when you only want floats. And to the extent that embedded C compilers offer such intelligence, that's great. I find it is rare, which is why the option to treat doubles as floats exists. Not that it practically matters-- just like with recursion, floating point numbers in embedded applications are rare. So feel free to continue cry out in objection to something that is both optional and has no practical effect for most people. > > Targeting the processors themselves would be more > > for signal processing, implementing hardware, etc. > > If you want a HLL for that, C just seems like a terrible > choice. Better to concoct some DSL that carefully tracks > the stack content, has interprocedural optimization, > knows about inter-node communication, etc. And here we come back full circle to my original point. The reason why you (and undoubtedly others) think C is a poor language at this level is that you are taking a set of expectations and assumptions from larger systems. I'm not. I'm fully aware of the quality of code compilers *designed* for small, resource-constrained systems can generate, and I'm fully aware of the kind of optimizations that are possible in such compilers when generating code that doesn't treat a 8-bit system with small memory as if it was the same. I am not making an argument that a C compiler would generate better quality code than hand-tuned Forth. Clearly the GA144 is designed with Forth in mind. But for people who want to leverage their experience in C (especially embedded C), I see it as a valid approach, and I still believe the results could (potentially) be good.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-05-05 04:39 -0400 |
| Message-ID | <ado4s6h7ljj2mpsa6drdbdjnsr5vtm9tpl@4ax.com> |
| In reply to | #1607 |
On Wed, 27 Apr 2011 22:39:30 -0700, Paul Rubin <no.email@nospam.invalid> wrote: > John Passaniti <john.passaniti@gmail.com> writes: <snip most> > > More to the point, if you are using reals, you are > > more than likely also using a routine in math.h, and if you look at > > the prototypes, nearly every one of them accepts one or more doubles > > The version I'm looking at (glibc's) is conditionalized to use doubles > or floats. Andrew would know more about it, but IIRC the C standards > folks put some effort into getting stuff straightened out in C99 so you > don't get doubles when you only want floats. > C99 adds float and long-double versions of the math.h routines, plus generic names that select precision matching the argument. The former I don't believe required much effort by the committee, since it just straightforwardly adds similar entries to existing list. *Implementors* of course had to do some work, although on non-tiny targets the float routines can just be thin wrappers on the double ones; on systems where long double is the same as double, that's just an alias; and even where long double is in fact longer, a lazy or overburdened implementor might get away with wrapping double and excusing it as a low quality approximation. The latter I believe did since generic is a whole new thing for C, although well explored in several other languages. OTOH even after 11 years compliance to C99 is not exactly wildfire. Although implementors can always do selected features; if e.g. your users want tgmath.h but not VLA, well, you can't call it C99 but it can still be useful. Recent C1X drafts even propose some subsetting.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-05-05 04:10 -0500 |
| Message-ID | <W-ednY3B_JcD9F_QnZ2dnUVZ7sWdnZ2d@supernews.com> |
| In reply to | #1773 |
David Thompson <dave.thompson2@verizon.net> wrote: > OTOH even after 11 years compliance to C99 is not exactly wildfire. There are very few complete C99 implementations. GCC is nearly complete, save mostly for a few features so inconsequential that no-one can be bothered to implement them. Is it worth doing the rest just to get a "C99 compatible" tick box? I can understand why it might be, but it doesn't seem to matter to most people. > Although implementors can always do selected features; if e.g. your > users want tgmath.h but not VLA, well, you can't call it C99 but it > can still be useful. Recent C1X drafts even propose some subsetting. That's a good idea. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-04-23 09:53 +0000 |
| Message-ID | <4db2a103.220142168@192.168.0.50> |
| In reply to | #1398 |
On Thu, 21 Apr 2011 21:11:30 -0700 (PDT), foxchip <fox@ultratechnology.com> wrote: >The programmers who preferred C insisted that a lot more >stack registers would be needed on c18. The Forth programmers >showed how many were actually needed. Since the stacks use >about as much real-estate as on-chip RAM and ROM combined >Chuck didn't want to make more than were actually needed. I think that it is fair comment to say that the S24/40 and C18 cores are not suitable for C. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-04-23 14:59 -0700 |
| Message-ID | <ba8c4f96-ec63-4560-b872-19f8dc97fd3c@z33g2000vbk.googlegroups.com> |
| In reply to | #1455 |
On Apr 23, 5:53 am, stephen...@mpeforth.com (Stephen Pelc) wrote: > I think that it is fair comment to say that the S24/40 > and C18 cores are not suitable for C. Not designed or intended for C, sure. But lots of processors that are hostile to C exist and vendors have created C compilers for them-- just as there are processors that *are* designed for C but are relatively hostile to Forth. But that doesn't stop people from creating Forths for them. There is always the question of if a particular language is optimal for a particular processor architecture, but for many the goal is less about optimality and more about pragmatism. So let's have some fun. You tell me what specific attributes of those processors are not suitable for C, and I'll tell you what assumptions you're bringing to the table about implementation strategies for C. And I'll probably be able to point to some real-world C compiler for an embedded system that I've used that had the same or similar challenge, but was able to come up with a clever or otherwise functional solution.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-23 16:10 -0700 |
| Message-ID | <c26123d9-34e0-418c-b4a1-b07ddb832eeb@u15g2000vby.googlegroups.com> |
| In reply to | #1472 |
On Apr 23, 5:59 pm, John Passaniti <john.passan...@gmail.com> wrote: > But lots of processors that are > hostile to C exist and vendors have created C compilers for them-- > just as there are processors that *are* designed for C but are > relatively hostile to Forth. But that doesn't stop people from > creating Forths for them. The 6502 is relatively hostile to both Forth and C, but that was the target of the venerable fig-Forth implementation, a variety of 6502 system hosted C compilers emerged and in the day that it had passed from the general computing space but still used as an inexpensive embedded processor, a number of C cross compilers as well. Meanwhile the 65816 which is much friendlier to both C and Forth was mostly a chip in the SuperNES and didn't get nearly the same attention from either.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-05-01 23:47 -0700 |
| Message-ID | <7xr58hsior.fsf@ruckus.brouhaha.com> |
| In reply to | #1472 |
John Passaniti <john.passaniti@gmail.com> writes: >> I think that it is fair comment to say that the S24/40 >> and C18 cores are not suitable for C. > So let's have some fun. You tell me what specific attributes of those > processors are not suitable for C, and I'll tell you what assumptions > you're bringing to the table about implementation strategies for C. I'd be interesteed in your thoughts about handling the 18-bit word size with no byte addressing, making it painful to deal with the pervasive use of 8-bit characters in real-world C programs and the protocols that they implement. This includes the expectation that pointers to chars will do something reasonable. Making 1-char=1 word (wasting 55% of the memory) is a non-starter. 2 bytes/word is ok, though it would be really nice to avoid serial shifting to get to the upper byte, making dereferencing an odd-address pointer an order of magnitude slower than an even address (or the other way around, depending on how you assign endianness).
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-05-03 14:23 -0700 |
| Message-ID | <3e55f8d7-256e-4367-8b99-c9e18a937be2@y12g2000yqh.googlegroups.com> |
| In reply to | #1693 |
On May 2, 2:47 am, Paul Rubin <no.em...@nospam.invalid> wrote: > I'd be interesteed in your thoughts about handling the 18-bit > word size with no byte addressing, making it painful to deal > with the pervasive use of 8-bit characters in real-world C > programs and the protocols that they implement. How about before we have that discussion, we first discuss if the "real-world C programs and the protocols that they implement" make sense for this target?" That's not a question you seem to be asking much in this thread. When I talk about a C compiler for nodes of the GA144, I'm not in any way thinking of taking generic C code and expecting it to run efficiently. The GA144 is a chip designed for purpose-built systems; it's not a generic processor. So if you expect to just copy C code you've written elsewhere and have it run on the chip's nodes, then you're not being rational. If you want to be able to do that, then yeah, set up an efficient VM and have it execute some abstracted representation of your code. That's useful if in addition to doing the kind of processing the GA144 is designed to do (mostly, digital signal processing and hardware control) you want to dedicate some nodes for a lower-speed application processor. Much the same way a FPGA designer might instantiate hardware for DSP and hardware control, and also instantiate a "soft" processor for control and coordination. I don't want that. I'm interested in the kinds of processing for the nodes that I see make sense for the kind of work I do. Things like audio DSP algorithms, where 8-bit character data is irrelevant. Things like generating various digital and analog waveforms. I also don't think your question can be answered without talking about the larger application and how data will flow between the nodes. A C compiler for nodes of the GA144 may be quixotic. My goal wouldn't be to claim a *better* language for development than ArrayForth. The goal would be to measure how much worse it would be for the kinds of applications where it makes sense. One of the things I'm betting on is that in most applications for the GA144, the amount of program space used per processor is likely to be on average small. For example, say I wanted to implement a D/A converter for audio. Samples fly in through the communication port at some fixed rate, and I use that to change the duty cycle of a square wave coming out of a pin. Of the 256-ish instructions possible for a particular processor (64 words by up to four instructions per word), I imagine a tightly coded loop for that processor would likely take no more than 32-ish instructions, or 12.5-ish of the address space. Let's say a C compiler generating code took double that. That still easily fits in the processor.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-05-04 01:48 -0700 |
| Message-ID | <7xaaf2j1gx.fsf@ruckus.brouhaha.com> |
| In reply to | #1718 |
John Passaniti <john.passaniti@gmail.com> writes: > How about before we have that discussion, we first discuss if the > "real-world C programs and the protocols that they implement" make > sense for this target?" That's not a question you seem to be asking > much in this thread. Shrug. You were the one offering to explain C implementation strategy for these processors. Bytes and characters are pervasive in C, but your prescription seems to be "ignore them". Cryptography was one of the suggested applications of the GA chip on the old version of the web site. They seem to have gotten rid of that now, which is probably a good thing. Most cryptographic primitives I can think of make heavy use of 8-bit operations (32 bit in some cases), multi-bit rotations, etc. > So if you expect to just copy C code you've written elsewhere and have > it run on the chip's nodes,.. If you want to be able to do that, then > yeah, set up an efficient VM and have it execute some abstracted > representation of your code. ...That's useful if ... you want to > dedicate some nodes for a lower-speed application processor. Right, we're back to how this started. I brought up Greg Bailey's suggestion of a VM and you criticized it saying to target the node processors directly. > I don't want that. I'm interested in the kinds of processing for the > nodes that I see make sense for the kind of work I do. Things like > audio DSP algorithms, where 8-bit character data is irrelevant. The most ubiquitous audio DSP algorithms that need a lot of cpu power are probably mobile phone speech codecs. And then you get to deal with packet formats, error correction codes, etc., all of which involve 8-bit character data. > For example, say I wanted to implement a D/A converter for audio. > Samples fly in through the communication port at some fixed rate, and > I use that to change the duty cycle of a square wave coming out of a > pin. Of the 256-ish instructions possible for a particular processor > (64 words by up to four instructions per word), I imagine a tightly > coded loop for that processor would likely take no more than 32-ish > instructions, or 12.5-ish of the address space. Let's say a C > compiler generating code took double that. That still easily fits in > the processor. That sounds like the -DAC word that's already in the ROM of the GA144 analog nodes (sec 3.2 of the GA144 data book). In any case I don't see much gained from writing a 5-line function in C instead of Forth in a situation like that. I do take your point that the GA144 is really built for signals rather than character data, and it took a while for this to sink in for me. Recall that the early discussions of possible applications for it included things like disk controllers, I can't help wondering if they could have improved DSP performance quite a lot by making the ALU a little bigger. That wouldn't increase the node size that much, since the node (in the photos) seems dominated by the ram, rom, and stacks.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-05-04 05:23 -0500 |
| Message-ID | <e-udnWgzG92CtFzQnZ2dnUVZ8m2dnZ2d@supernews.com> |
| In reply to | #1733 |
Paul Rubin <no.email@nospam.invalid> wrote: > John Passaniti <john.passaniti@gmail.com> writes: >> How about before we have that discussion, we first discuss if the >> "real-world C programs and the protocols that they implement" make >> sense for this target?" That's not a question you seem to be asking >> much in this thread. > > Shrug. You were the one offering to explain C implementation strategy > for these processors. Bytes and characters are pervasive in C, ... I don't think that's really true: bytes, or to be more precise, octets, are used for problems that require them. C is used in other areas, many of which don't require them for much other than a little byte-oriented I/O. And, as I'm sure you know, you can have a compliant implementation of C without needing 8-bit bytes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <jpassaniti@ashly.com> |
|---|---|
| Date | 2011-05-04 11:17 -0700 |
| Message-ID | <69e4a95f-55eb-4ef5-a409-ee2a6fcb03b0@p18g2000yqj.googlegroups.com> |
| In reply to | #1733 |
On May 4, 4:48 am, Paul Rubin <no.em...@nospam.invalid> wrote: > Shrug. You were the one offering to explain C implementation > strategy for these processors. Bytes and characters are > pervasive in C, but your prescription seems to be "ignore them". Bytes and characters are pervasive in C code that uses bytes and characters. They are not pervasive in C code written for DSP targets. They are not pervasive in C code written to talk to control registers that are not a 8-bits wide. Gosh, how wide are the control and communication registers of the GA144... If I remember correctly, C only requires that the size (in bits) of the primitive integer types must maintain that char <= short <= int (and probably <= long too). It would be unusual to have a target architecture where the sizes of those primitive integer types were all the same, but permitted if that made sense. And here, it probably does. It would be unusual, but as I've pointed out before, with embedded systems, unusual is the status quo. But sure, to answer the question, handling 8-bit quantities is obviously possible in the trivial sense by wasting the extra bits. You said this was a "non-starter" but that's entirely dependent on what you're trying to do. The GA144 architecture certainly seems to me to be structured around the idea of processing streams of data. So if that 8-bit data is flowing through a node, I don't see a problem with wasting bits. Where it becomes a problem is if you want to *store* that data in a node. Then you're gobbling up precious memory. Storage would require packing or some other encoding and would burn more cycles. Let's take a real-world example where wasting space doesn't matter. In the UDP-based control protocol used by my company's line of signal processors and amplifiers, packets contain streams of instructions. It's all 8-bit data, but each instruction has a structure like this: instruction byte length byte payload (0 to 255 bytes of data) There is more to the protocol, obviously, but I'm breaking it down to it's essence. In our products, it makes sense to take the block of data that we received from the Ethernet MAC and return an 8-bit pointer to the start of the instructions. Then we do the obvious thing-- create a while loop that bumps the pointer as appropriate over this data, processing it byte-by-byte. The more stream-oriented architecture of the GA144 suggests a different organization. Presuming I had some nodes handling the networking aspect, I wouldn't somehow pass the entire buffer to a GA144 node and have it spin over the bytes of that buffer. Instead, I would imagine a better (or at least more natural) architecture would be for some node to spit out each byte of the Ethernet frame to a GA144 node that used a state machine of some sort to process the data sent to it, byte by byte. My point is that on an architecture (like the ColdFire that we use in our products), processing blocks of 8-bit data follows an common, expected processing structure that makes sense for a processor designed (in part) to easily handle 8-bit data. You could take the code we wrote and compile it on pretty much any common processor and it would work just fine. But on the GA144, the architecture demands you think about what you're doing. If your first move is to do the canonical thing you would on a different processor, you're going to fail. If you consider the strengths and weaknesses of the part, then you can probably think of ways to do what you want that make better sense. > Cryptography was one of the suggested applications of the GA > chip on the old version of the web site. They seem to have > gotten rid of that now, which is probably a good thing. Most > cryptographic primitives I can think of make heavy use of > 8-bit operations (32 bit in some cases), multi-bit rotations, etc. You mean most *standard* cryptographic algorithms make heavy use of 8- bit operations. So say for example that you wanted to compute a hash for some block of data so that you could quickly determine if that block of data wasn't corrupted (within some large probability, of course). If that block of data comes from some system where juggling 8-bit quantities is natural, then yeah, you'll probably need to burn cycles. But what if the block of data was from another GA144 that is using a hash that is better tuned to the 18-bit word width? Here is my biggest assumption regarding the GA144: I assume that Charles Moore and the other fine folk at GreenArrays didn't just pick an 18-bit word width at random or because older designs were 18 bit. My assumption is that they have in mind certain applications (or at least certain classes of applications) where 18-bits makes perfect sense. There are certainly aspects of the GA144 that seem openly hostile to the byte-oriented world I, you, and most other people usually work in. But if those applications weren't intended for the GA144, then who cares? It's no different than your shock and horror over some C compiler's option of "compiled stack." If the vast majority of applications don't need recursion (or only need it in a limited way), then in what sense is "compiled stack" a serious limitation? If you go to a restaurant and the waitress announces they are out of asparagus-- and you hate asparagus-- are you going to be disappointed? In the kinds of applications I would consider a GA144 for (mostly signal processing), I don't think it would be a very good fit. The systems I work on are processing multiple channels of digital audio that's typically 24 bits wide. In reality, you'll find that most A/D converters have a couple or more bits of noise, but even in the worst case, you're still dealing with more than 18 "good" bits. So I would be forced to do double-precision math for practically all audio processing to get the same quality as what we get now with the DSPs we use. Could I do it? Sure. Does it make sense? Probably not; in those specific applications that I'm interested in, the GA144 wouldn't offer a compelling advantage over existing parts. Saving a few picowatts when the system is putting out a couple thousand watts to a speaker array doesn't excite me much. And that's fine. The people behind the GA144 are smart people, and I'm sure they've carefully thought about both the applications where the GA144 shines, and the applications where it doesn't make sense. And so they've factored that into the design of the chip, and likely other aspects of the business, like who they will market the chip to. So when thinking about this chip, I would start there. Instead of thinking about how painful the chip may be to process 8-bit data, ask instead what kinds of applications the chip is designed for and how well it does that. > Right, we're back to how this started. I brought up Greg > Bailey's suggestion of a VM and you criticized it saying > to target the node processors directly. I don't think I criticized it. I see where it makes sense, but I'm not interested in using the GA144 as a replacement for a control processor. I see the GA144 as less competitive with generic microcontrollers and more competitive with FPGAs and DSPs. And because of my experience in how C compilers have targeted resource- constrained systems, I can easily see a C compiler that directly targeted nodes. You're not interested in that, apparently. You want to view the GA144 as a generic microcontroller and do the exact same kinds of processing on it as any other commodity microcontroller-- with the same code. > The most ubiquitous audio DSP algorithms that need a lot of > cpu power are probably mobile phone speech codecs. And then > you get to deal with packet formats, error correction codes, > etc., all of which involve 8-bit character data. That's a bizarre statement. First, it doesn't matter what audio DSP algorithms are ubiquitous. What matters is what algorithms would be run on a GA144. Unless you believe that the GA144 is being positioned as a replacement for the various processors in cell phones, the number of devices that use speech codecs is irrelevant. You keep thinking in terms common applications, not what the GA144 is designed for. In the industry I work in, we apply a variety of signal processing algorithms to audio, and we transport it over network transports. Most professional audio applications (which is the industry I work in) use raw samples without any encoding, and because that data is usually over wired networks, there is no error detection or correction because the transports are reliable, isolated, and the latencies wouldn't allow for it anyway. So no, at least in my industry, there isn't much 8-bit in what we do. And what 8-bit oriented stuff there is could be treated as a stream or would be a candidate for a slower virtual processor. > I do take your point that the GA144 is really built for > signals rather than character data, and it took a while > for this to sink in for me. Recall that the early > discussions of possible applications for it included > things like disk controllers, I can't help wondering > if they could have improved DSP performance quite a lot > by making the ALU a little bigger. That wouldn't > increase the node size that much, since the node (in the > photos) seems dominated by the ram, rom, and stacks. Assuming the GreenArrays people all collectively did their jobs, the GA144 was designed as it is for good reason. Assuming that's the case, and assuming they can find ways to bootstrap developers on what is a somewhat unusual architecture, they should be fine. If on the other hand various design decisions were made by someone saying, "gosh, this should be enough" then they'll fail. I would certainly hope for the former rather than the latter.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-05-04 12:03 -0700 |
| Message-ID | <a0cff58c-0baf-42ba-a74f-cbbc0dc4c54f@p13g2000yqh.googlegroups.com> |
| In reply to | #1745 |
On May 4, 2:17 pm, John Passaniti <jpassan...@ashly.com> wrote: > Here is my biggest assumption regarding the GA144: I assume that > Charles Moore and the other fine folk at GreenArrays didn't just pick > an 18-bit word width at random or because older designs were 18 bit. > My assumption is that they have in mind certain applications (or at > least certain classes of applications) where 18-bits makes perfect > sense. For text, most text generated in UTF32 fits in the lower 64K codepoints ... b17 = data/text b16 = partial high word / final low word b0-b15 = data ... big endian and a low word w/out high implies high word 0, and you have a stream of UTF32 (internally dropped from two words to one word for the bottom 64K codepoints where basically all European text and the majority of Chinese ideograms reside) interleaved with accompanying 17bit data, or variable length data in multiples of 16bits. As specified above, that is simultaneously ASCII zero extended. And of course, with b17=data/text, a pure datastream has a spare bit to bring a carry along for the ride until it hits the node where its propagated.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-23 23:59 -0700 |
| Message-ID | <3493faa6-565f-4d80-8b6a-1f3e3ccad068@a19g2000prj.googlegroups.com> |
| In reply to | #1455 |
On Apr 23, 1:53 am, stephen...@mpeforth.com (Stephen Pelc) wrote: > On Thu, 21 Apr 2011 21:11:30 -0700 (PDT), foxchip > I think that it is fair comment to say that the S24/40 and > C18 cores are not suitable for C. Sure. It would seem more reasonable to use a group of processors to implement a virtual machine layer with all the features that C expects if one wants to run C. The whole idea behind all those generations of small Forth chips is that efficient Forth has far more modest hardware requirements than C. You really can't do C processors that are as small or low power or have the performance/cost levels for the sorts of embedded things where Forth is ideally suited. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-05-01 23:48 -0700 |
| Message-ID | <7xmxj5simr.fsf@ruckus.brouhaha.com> |
| In reply to | #1483 |
foxchip <fox@ultratechnology.com> writes: > Sure. It would seem more reasonable to use a group of processors > to implement a virtual machine layer with all the features that > C expects if one wants to run C. Yes, I've wondered (mentioned already) whether the Eforth VM already in the GA144 rom would also be suitable as a C VM. But John is talking about compiling C code directly to the F18.
[toc] | [prev] | [next] | [standalone]
Page 6 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