Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26771 > unrolled thread
| Started by | John Speth <johnspeth@yahoo.com> |
|---|---|
| First post | 2017-06-14 10:44 -0700 |
| Last post | 2017-06-19 12:23 -0400 |
| Articles | 20 on this page of 121 — 18 participants |
Back to article view | Back to comp.arch.embedded
MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-14 10:44 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-14 16:30 -0700
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-14 21:54 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:01 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 12:13 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 18:01 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 16:52 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 23:37 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:15 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 09:25 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 13:52 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-18 22:56 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:21 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 09:02 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 08:36 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 14:47 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:23 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 15:34 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:16 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 09:49 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 22:44 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 12:10 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:40 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 18:19 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 14:34 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:41 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 17:14 -0400
Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 13:54 -0700
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 23:33 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 23:12 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-16 07:05 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 02:27 -0400
Re: MCU mimicking a SPI flash slave Tim Wescott <seemywebsite@myfooter.really> - 2017-06-14 23:17 -0500
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:03 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 09:14 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:25 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:02 +0200
Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 16:25 +0800
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:32 +0200
Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 21:48 +0800
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:09 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 09:41 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 13:04 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 12:31 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 14:20 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 17:46 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 13:21 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 13:55 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 16:34 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 15:40 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 00:47 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:47 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:15 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:50 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:16 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 18:00 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-22 11:24 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 12:12 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 14:22 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 03:15 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:54 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 10:30 +0200
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 12:54 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 13:49 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:28 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:19 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 16:23 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 23:57 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:36 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 08:20 -0400
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-19 14:44 +0000
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 21:39 +0200
Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-19 14:59 -0500
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-20 09:25 +0200
Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-20 11:50 -0500
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:37 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 22:59 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:12 -0400
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 10:25 +0300
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 10:44 +0200
Re: MCU mimicking a SPI flash slave dp <dp@tgi-sci.com> - 2017-06-20 02:36 -0700
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 11:25 +0100
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 13:49 +0300
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 12:54 +0100
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 16:09 +0300
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 15:24 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 17:46 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 22:28 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 00:58 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 13:08 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:28 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:58 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:57 +0200
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 14:19 +0300
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:19 +0200
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:12 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:48 +0200
Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-20 21:16 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 23:15 +0200
Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-21 07:30 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:54 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:29 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 15:05 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:34 +0100
Re: MCU mimicking a SPI flash slave "Elizabeth D. Rather" <erather@forth.com> - 2017-06-21 18:04 -1000
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-22 10:26 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:56 -0400
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-22 09:20 +0000
Re: MCU mimicking a SPI flash slave Wasell <from_usenet@wasell.eu> - 2017-06-22 14:02 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:59 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:58 -0400
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-22 08:19 +0000
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-19 09:53 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:16 +0100
Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 13:56 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-15 14:41 -0700
Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 15:08 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-16 11:34 -0700
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:20 -0400
Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 07:58 -0700
Re: MCU mimicking a SPI flash slave Walter Banks <walter@bytecraft.com> - 2017-06-19 12:23 -0400
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2017-06-20 02:36 -0700 |
| Message-ID | <fedf5600-b506-4769-94eb-7e0e466ea1b3@googlegroups.com> |
| In reply to | #26868 |
On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: > On 20/06/17 09:25, Dimiter_Popoff wrote: > > On 20.6.2017 г. 07:12, rickman wrote: > >>.... > >> > >> So you think for a language to be modern it has to have hard coded data > >> sizes? > > If you are going to use it for low-level programming and embedded > development, then yes. No. If you don't know which datum of which size and type is you are not up to programming. Delegating to the tool to track that means only more work for the programmer, sometimes a lot more while tracking what the tool got wrong _this_ time. > > Programmers should use their ability to count not just for stack levels, > > it is a lot more effective than working to delegate the counting of > > this and that to a tool which is a lot less intelligent than the > > programmer. Just let the tool do the heavy lifting exercises, counting > > is not one of these. > > > > Counting is one of the tasks I expect a computer - and therefore a > programming language and a toolchain - to do well. I expect the tool to > do the menial stuff and let the programmer get on with the thinking. If "counting" is too much of a workload is too much for a person he is not in the right job as a programmer (hopefully "counting" is not taken literally here, it means more "counting up to ten"). Delegating simple tasks to the tool makes life harder, not easier, as I said above. Often a lot harder. Controlled types, sizes etc. by the machine are meant for the user, not for the programmer. They are supposed to make these work, this *is* their job. Pretty much like a meal is supposed to be served nicely arranged on a plate for the consumer; however for the cook the ingredients are a lot more convenient in a raw form. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-20 11:25 +0100 |
| Message-ID | <LK62B.1$iq5.0@fx07.am4> |
| In reply to | #26870 |
On 20/06/17 10:36, dp wrote: > On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: >> On 20/06/17 09:25, Dimiter_Popoff wrote: >>> On 20.6.2017 г. 07:12, rickman wrote: >>>> .... >>>> >>>> So you think for a language to be modern it has to have hard coded data >>>> sizes? >> >> If you are going to use it for low-level programming and embedded >> development, then yes. > > No. If you don't know which datum of which size and type is you are > not up to programming. Delegating to the tool to track that means > only more work for the programmer, sometimes a lot more while tracking > what the tool got wrong _this_ time. Er. No. David is suggesting, correctly IMNSHO, that sometimes it is necessary for me to specify exactly what the tool has to achieve - and then to let the tool do it in any way it sees fit. He gave a good example of that, which you snipped. With types such as uint8_t, uint_fast8_t and uint_least8_t, modern C is a significant advance over K&R C. >>> Programmers should use their ability to count not just for stack levels, >>> it is a lot more effective than working to delegate the counting of >>> this and that to a tool which is a lot less intelligent than the >>> programmer. Just let the tool do the heavy lifting exercises, counting >>> is not one of these. >>> >> >> Counting is one of the tasks I expect a computer - and therefore a >> programming language and a toolchain - to do well. I expect the tool to >> do the menial stuff and let the programmer get on with the thinking. > > If "counting" is too much of a workload is too much for a person he > is not in the right job as a programmer (hopefully "counting" is not > taken literally here, it means more "counting up to ten"). > Delegating simple tasks to the tool makes life harder, not easier, > as I said above. Often a lot harder. I can only easily deal with three numbers: 0, 1, many :) All other numbers are a pain in the ass and I'm more than happy to delegate them to a tool.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-06-20 13:49 +0300 |
| Message-ID | <oiauc6$43d$1@dont-email.me> |
| In reply to | #26871 |
On 20.6.2017 г. 13:25, Tom Gardner wrote: > On 20/06/17 10:36, dp wrote: >> On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: >>> On 20/06/17 09:25, Dimiter_Popoff wrote: >>>> On 20.6.2017 г. 07:12, rickman wrote: >>>>> .... >>>>> >>>>> So you think for a language to be modern it has to have hard coded >>>>> data >>>>> sizes? >>> >>> If you are going to use it for low-level programming and embedded >>> development, then yes. >> >> No. If you don't know which datum of which size and type is you are >> not up to programming. Delegating to the tool to track that means >> only more work for the programmer, sometimes a lot more while tracking >> what the tool got wrong _this_ time. > > Er. No. > > David is suggesting, correctly IMNSHO, that sometimes > it is necessary for me to specify exactly what the > tool has to achieve - and then to let the tool do it > in any way it sees fit. > > He gave a good example of that, which you snipped. > > With types such as uint8_t, uint_fast8_t and uint_least8_t, > modern C is a significant advance over K&R C. It may be an improvement in C indeed. But this is not relevant to the main point: delegating simple tasks to the tool costs the programmer more, often a lot more effort than it returns. > >>>> Programmers should use their ability to count not just for stack >>>> levels, >>>> it is a lot more effective than working to delegate the counting of >>>> this and that to a tool which is a lot less intelligent than the >>>> programmer. Just let the tool do the heavy lifting exercises, counting >>>> is not one of these. >>>> >>> >>> Counting is one of the tasks I expect a computer - and therefore a >>> programming language and a toolchain - to do well. I expect the tool to >>> do the menial stuff and let the programmer get on with the thinking. >> >> If "counting" is too much of a workload is too much for a person he >> is not in the right job as a programmer (hopefully "counting" is not >> taken literally here, it means more "counting up to ten"). >> Delegating simple tasks to the tool makes life harder, not easier, >> as I said above. Often a lot harder. > > I can only easily deal with three numbers: 0, 1, many :) > All other numbers are a pain in the ass and I'm more > than happy to delegate them to a tool. Well you snipped my example with the programmer and the cook, let me repost it: >> Pretty much like a meal is supposed to be served nicely >> arranged on a plate for the consumer; however for the cook the >> ingredients are a lot more convenient in a raw form. In the case you let the tool do all the cooking for you you relegate yourself to the role of the waiter if not the consumer. And if you have to do the job of the cook having kept yourself fit only about the skill set of a waiter - it will cost you a lot more time to do the job than it would cost you had you not lef your cooking skills decay. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-20 12:54 +0100 |
| Message-ID | <n282B.1$9u1.0@fx06.am4> |
| In reply to | #26873 |
On 20/06/17 11:49, Dimiter_Popoff wrote: > On 20.6.2017 г. 13:25, Tom Gardner wrote: >> On 20/06/17 10:36, dp wrote: >>> On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: >>>> On 20/06/17 09:25, Dimiter_Popoff wrote: >>>>> On 20.6.2017 г. 07:12, rickman wrote: >>>>>> .... >>>>>> >>>>>> So you think for a language to be modern it has to have hard coded >>>>>> data >>>>>> sizes? >>>> >>>> If you are going to use it for low-level programming and embedded >>>> development, then yes. >>> >>> No. If you don't know which datum of which size and type is you are >>> not up to programming. Delegating to the tool to track that means >>> only more work for the programmer, sometimes a lot more while tracking >>> what the tool got wrong _this_ time. >> >> Er. No. >> >> David is suggesting, correctly IMNSHO, that sometimes >> it is necessary for me to specify exactly what the >> tool has to achieve - and then to let the tool do it >> in any way it sees fit. >> >> He gave a good example of that, which you snipped. >> >> With types such as uint8_t, uint_fast8_t and uint_least8_t, >> modern C is a significant advance over K&R C. > > It may be an improvement in C indeed. But this is not relevant > to the main point: delegating simple tasks to the tool costs > the programmer more, often a lot more effort than it returns. For the examples given you haven't demonstrated your point, and you have ignored the main point being made. To repeat the main point being made: it is better for me to specify (in the source code) what the tool has to achieve, and let the compiler decide how to achieve it. It is worse for me to /ambiguously/ specify (in the source code) what is required, and to implicitly point to the compiler's man pages - and probably to hope the next program maintainer uses the correct compiler flags. >>>>> Programmers should use their ability to count not just for stack >>>>> levels, >>>>> it is a lot more effective than working to delegate the counting of >>>>> this and that to a tool which is a lot less intelligent than the >>>>> programmer. Just let the tool do the heavy lifting exercises, counting >>>>> is not one of these. >>>>> >>>> >>>> Counting is one of the tasks I expect a computer - and therefore a >>>> programming language and a toolchain - to do well. I expect the tool to >>>> do the menial stuff and let the programmer get on with the thinking. >>> >>> If "counting" is too much of a workload is too much for a person he >>> is not in the right job as a programmer (hopefully "counting" is not >>> taken literally here, it means more "counting up to ten"). >>> Delegating simple tasks to the tool makes life harder, not easier, >>> as I said above. Often a lot harder. >> >> I can only easily deal with three numbers: 0, 1, many :) >> All other numbers are a pain in the ass and I'm more >> than happy to delegate them to a tool. > > Well you snipped my example with the programmer and the cook, let > me repost it: I ignored it because, like most analogies, its relevance is dubious and encourage focusing the attention on /inapplicable/ details. That has already started happening in another response which has started to discuss menus/meals that people had last week! I beats me how that is supposed to illuminate the benefits of stating the peripheral's structure and letting a compiler sort out how best to generate code for it.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-06-20 16:09 +0300 |
| Message-ID | <oib6je$vjk$1@dont-email.me> |
| In reply to | #26877 |
On 20.6.2017 г. 14:54, Tom Gardner wrote: > On 20/06/17 11:49, Dimiter_Popoff wrote: >> On 20.6.2017 г. 13:25, Tom Gardner wrote: >>> On 20/06/17 10:36, dp wrote: >>>> On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: >>>>> On 20/06/17 09:25, Dimiter_Popoff wrote: >>>>>> On 20.6.2017 г. 07:12, rickman wrote: >>>>>>> .... >>>>>>> >>>>>>> So you think for a language to be modern it has to have hard coded >>>>>>> data >>>>>>> sizes? >>>>> >>>>> If you are going to use it for low-level programming and embedded >>>>> development, then yes. >>>> >>>> No. If you don't know which datum of which size and type is you are >>>> not up to programming. Delegating to the tool to track that means >>>> only more work for the programmer, sometimes a lot more while tracking >>>> what the tool got wrong _this_ time. >>> >>> Er. No. >>> >>> David is suggesting, correctly IMNSHO, that sometimes >>> it is necessary for me to specify exactly what the >>> tool has to achieve - and then to let the tool do it >>> in any way it sees fit. >>> >>> He gave a good example of that, which you snipped. >>> >>> With types such as uint8_t, uint_fast8_t and uint_least8_t, >>> modern C is a significant advance over K&R C. >> >> It may be an improvement in C indeed. But this is not relevant >> to the main point: delegating simple tasks to the tool costs >> the programmer more, often a lot more effort than it returns. > > For the examples given you haven't demonstrated your point, > and you have ignored the main point being made. > > To repeat the main point being made: it is better for me > to specify (in the source code) what the tool has to achieve, > and let the compiler decide how to achieve it. It is worse > for me to /ambiguously/ specify (in the source code) what > is required, and to implicitly point to the compiler's man > pages - and probably to hope the next program maintainer uses > the correct compiler flags. Oh I did make my point all right, check my first post on the thread. The examples are completely beside my point, they are about C specifics and sort of. > >>>>>> Programmers should use their ability to count not just for stack >>>>>> levels, >>>>>> it is a lot more effective than working to delegate the counting of >>>>>> this and that to a tool which is a lot less intelligent than the >>>>>> programmer. Just let the tool do the heavy lifting exercises, >>>>>> counting >>>>>> is not one of these. >>>>>> >>>>> >>>>> Counting is one of the tasks I expect a computer - and therefore a >>>>> programming language and a toolchain - to do well. I expect the >>>>> tool to >>>>> do the menial stuff and let the programmer get on with the thinking. >>>> >>>> If "counting" is too much of a workload is too much for a person he >>>> is not in the right job as a programmer (hopefully "counting" is not >>>> taken literally here, it means more "counting up to ten"). >>>> Delegating simple tasks to the tool makes life harder, not easier, >>>> as I said above. Often a lot harder. >>> >>> I can only easily deal with three numbers: 0, 1, many :) >>> All other numbers are a pain in the ass and I'm more >>> than happy to delegate them to a tool. >> >> Well you snipped my example with the programmer and the cook, let >> me repost it: > > I ignored it because, like most analogies, its > relevance is dubious and encourage focusing the > attention on /inapplicable/ details. > > That has already started happening in another > response which has started to discuss menus/meals > that people had last week! Like it or not thinking is about making analogies. I realize my point is probably doomed to never come across to the vast majority of programmers today, sort of like trying to explain colours to a blind person (absolutely no insult meant here, I know I am talking to intelligent people, just wrestling to make a point). What I see from where I stand is that C as a language - not as a compiler, toolchain quality etc. - costs a lot more work to the programmer than needed. One of the reasons for that is the fact that the programmer has to delegate to the toolchain a lot of trivial "no brainer" work and _this_ costs a significant, at times a prohibitive, effort. How do I make my point to people who have never been really fluent in a lower level language which does not have the ugliness of a poor underlying model etc... A lost cause I guess. > > I beats me how that is supposed to illuminate > the benefits of stating the peripheral's structure > and letting a compiler sort out how best to generate > code for it. > It is not supposed to illuminate that. It is supposed to demonstrate that while wrestling with the compiler to make it do this or that one can often waste a lot more time if he could omit this step. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-20 15:24 +0100 |
| Message-ID | <bea2B.1$TL4.0@fx04.am4> |
| In reply to | #26881 |
On 20/06/17 14:09, Dimiter_Popoff wrote: > Like it or not thinking is about making analogies. I realize > my point is probably doomed to never come across to the vast > majority of programmers today, sort of like trying to explain > colours to a blind person (absolutely no insult meant here, I > know I am talking to intelligent people, just wrestling to make > a point). Yeah. Been there done that :( > What I see from where I stand is that C as a language - not as > a compiler, toolchain quality etc. - costs a lot more work to > the programmer than needed. One of the reasons for that is the > fact that the programmer has to delegate to the toolchain a lot > of trivial "no brainer" work and _this_ costs a significant, at > times a prohibitive, effort. How do I make my point to people > who have never been really fluent in a lower level language > which does not have the ugliness of a poor underlying model etc... > A lost cause I guess. Oh, there we are in violent agreement about the end result! Overall C/C++ has (arguably) become too complex for simple things, and (unarguably IMNHSHO!) become too poorly specified for complex things. Trying to be "all things to all people" is rarely successful. Nowadays C (and even more with C++) is part of the problem rather than part of the solution. The abstractions, which were a useful valid advance in K&R days, have become *very* leaky over the years with the advance of technology. Hells teeth, it is only recently that C/C++ has recognised the need for a memory model to deal with all the subtle behaviour in SMP and NUMA machines. I reserve judgement on whether it will be a success; even starting from a clean slate Java had to revise its memory model!
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-20 17:46 +0100 |
| Message-ID | <sjc2B.3$Ik7.2@fx39.am4> |
| In reply to | #26883 |
On 20/06/17 15:24, Tom Gardner wrote: > Overall C/C++ has (arguably) become too complex for simple > things, and (unarguably IMNHSHO!) become too poorly > specified for complex things. > Nowadays C (and even more with C++) is part of the problem > rather than part of the solution. The abstractions, which > were a useful valid advance in K&R days, have become *very* > leaky over the years with the advance of technology. Examples I've come across include such gems as... "However, many C compilers use non-standard expression grammar where ?: is designated higher precedence than =, which parses that expression as e = ( ((a < d) ? (a++) : a) = d ), which then fails to compile due to semantic constraints: ?: is never lvalue and = requires a modifiable lvalue on the left. Note that this is different in C++, where the conditional operator has the same precedence as assignment." http://en.cppreference.com/w/c/language/operator_precedence "i = ++i + 1; // undefined behavior[in C] (well-defined in C++11)" http://en.cppreference.com/w/cpp/language/eval_order The ability to break a compiler's legitimate optimisations by "casting away constness and volatility" (IIRC that took several years of committee deliberation as to whether it was required or forbidden behaviour!) And of course, the amusing C++ FQA. All of which makes the simplicity of Forth seem appealing :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 22:28 +0200 |
| Message-ID | <oic0ap$sl1$1@dont-email.me> |
| In reply to | #26886 |
On 20/06/17 18:46, Tom Gardner wrote: > On 20/06/17 15:24, Tom Gardner wrote: >> Overall C/C++ has (arguably) become too complex for simple >> things, and (unarguably IMNHSHO!) become too poorly >> specified for complex things. >> Nowadays C (and even more with C++) is part of the problem >> rather than part of the solution. The abstractions, which >> were a useful valid advance in K&R days, have become *very* >> leaky over the years with the advance of technology. > > Examples I've come across include such gems as... > > "However, many C compilers use non-standard expression > grammar where ?: is designated higher precedence than =, > which parses that expression as > e = ( ((a < d) ? (a++) : a) = d ), which then fails to > compile due to semantic constraints: ?: is never lvalue > and = requires a modifiable lvalue on the left. Note > that this is different in C++, where the conditional > operator has the same precedence as assignment." > http://en.cppreference.com/w/c/language/operator_precedence > > "i = ++i + 1; // undefined behavior[in C] (well-defined in C++11)" > http://en.cppreference.com/w/cpp/language/eval_order > Neither C nor C++ is a problem here. People writing absurd obfuscated nonsense in their code may be a problem, but that applies in any language. > The ability to break a compiler's legitimate optimisations > by "casting away constness and volatility" (IIRC that took > several years of committee deliberation as to whether > it was required or forbidden behaviour!) "casting away constness and volatility" means writing code that explicitly tells the compiler "I know better than you do here, and I know it is safe to break rules about the code". Either that is true, and it lets you write the code you want, or it is wrong and you've made a mistake - as you can do in all languages. > > And of course, the amusing C++ FQA. Have you read it? It is mostly misunderstandings, repetitions, outdated information, or completely unrealistic code. There are a few good points in it, but you have to work hard to find them. > > All of which makes the simplicity of Forth seem appealing :) C is mostly simple and clear (if well written). C++ is a much bigger and more complex language - it has greater scope for writing good code, but also greater scope for making a mess. Simplicity of a language is not necessarily a good thing any more than complexity is - you don't get much simpler than a Turing machine, but I would not want to use it for application programming!
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-21 00:58 +0100 |
| Message-ID | <iEi2B.153$122.141@fx47.am4> |
| In reply to | #26889 |
On 20/06/17 21:28, David Brown wrote: > On 20/06/17 18:46, Tom Gardner wrote: >> On 20/06/17 15:24, Tom Gardner wrote: >>> Overall C/C++ has (arguably) become too complex for simple >>> things, and (unarguably IMNHSHO!) become too poorly >>> specified for complex things. >>> Nowadays C (and even more with C++) is part of the problem >>> rather than part of the solution. The abstractions, which >>> were a useful valid advance in K&R days, have become *very* >>> leaky over the years with the advance of technology. >> >> Examples I've come across include such gems as... >> >> "However, many C compilers use non-standard expression >> grammar where ?: is designated higher precedence than =, >> which parses that expression as >> e = ( ((a < d) ? (a++) : a) = d ), which then fails to >> compile due to semantic constraints: ?: is never lvalue >> and = requires a modifiable lvalue on the left. Note >> that this is different in C++, where the conditional >> operator has the same precedence as assignment." >> http://en.cppreference.com/w/c/language/operator_precedence >> >> "i = ++i + 1; // undefined behavior[in C] (well-defined in C++11)" >> http://en.cppreference.com/w/cpp/language/eval_order >> > > Neither C nor C++ is a problem here. People writing absurd obfuscated nonsense > in their code may be a problem, but that applies in any language. Agreed, but the differences between the two languages is a big hint that there are surprising and unnecessary dragons lurking to catch people that haven't spent several decades following the differences and /newly introduced/ pitfalls. Do you have any comment about the previous point about /some/ compilers apparently /choosing/ non-standard expression grammars? That seems remarkable to me. >> The ability to break a compiler's legitimate optimisations >> by "casting away constness and volatility" (IIRC that took >> several years of committee deliberation as to whether >> it was required or forbidden behaviour!) > > "casting away constness and volatility" means writing code that explicitly tells > the compiler "I know better than you do here, and I know it is safe to break > rules about the code". Either that is true, and it lets you write the code you > want, or it is wrong and you've made a mistake - as you can do in all languages. That is problematic when a library is compiled and optimised assuming that the const statements are correct, and later on someone else in a different company uses that library in a way which violates those assumptions. In those circumstances the user probably doesn't know better. >> And of course, the amusing C++ FQA. > > Have you read it? It is mostly misunderstandings, repetitions, outdated > information, or completely unrealistic code. There are a few good points in it, > but you have to work hard to find them. Indeed. But not all of the points can be "wished away"; many a truth is spoken in jest. >> All of which makes the simplicity of Forth seem appealing :) > > C is mostly simple and clear (if well written). C++ is a much bigger and more > complex language - it has greater scope for writing good code, but also greater > scope for making a mess. Simplicity of a language is not necessarily a good > thing any more than complexity is - you don't get much simpler than a Turing > machine, but I would not want to use it for application programming! I completely agree :) The major problem with C/C++ is that it can't make up its mind whether it wants to be simple low-level and near to the silicon, or an expressive high-level general purpose applications language. Either would be valid, but in trying to be both it misses both targets. Fortunately the marketplace has decided that in most cases C/C++ isn't "the best" general purpose application language; Java, Python and similar are the future there.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-21 13:08 +0200 |
| Message-ID | <oidjs9$b47$1@dont-email.me> |
| In reply to | #26891 |
On 21/06/17 01:58, Tom Gardner wrote: > On 20/06/17 21:28, David Brown wrote: >> On 20/06/17 18:46, Tom Gardner wrote: >>> On 20/06/17 15:24, Tom Gardner wrote: >>>> Overall C/C++ has (arguably) become too complex for simple >>>> things, and (unarguably IMNHSHO!) become too poorly >>>> specified for complex things. >>>> Nowadays C (and even more with C++) is part of the problem >>>> rather than part of the solution. The abstractions, which >>>> were a useful valid advance in K&R days, have become *very* >>>> leaky over the years with the advance of technology. >>> >>> Examples I've come across include such gems as... >>> >>> "However, many C compilers use non-standard expression >>> grammar where ?: is designated higher precedence than =, >>> which parses that expression as >>> e = ( ((a < d) ? (a++) : a) = d ), which then fails to >>> compile due to semantic constraints: ?: is never lvalue >>> and = requires a modifiable lvalue on the left. Note >>> that this is different in C++, where the conditional >>> operator has the same precedence as assignment." >>> http://en.cppreference.com/w/c/language/operator_precedence >>> >>> "i = ++i + 1; // undefined behavior[in C] (well-defined in C++11)" >>> http://en.cppreference.com/w/cpp/language/eval_order >>> >> >> Neither C nor C++ is a problem here. People writing absurd obfuscated >> nonsense >> in their code may be a problem, but that applies in any language. > > Agreed, but the differences between the two languages is a > big hint that there are surprising and unnecessary dragons > lurking to catch people that haven't spent several decades > following the differences and /newly introduced/ pitfalls. What pitfalls? Everyone who has ever been involved in C (or C++) knows that expressions like "i = ++i + 1;" are classic examples of undefined or unspecified behaviour. There is never a reason for writing such things in code, and it is always unclear to the reader (even in later C++ standards where some cases now have defined ordering). Just don't write such silly code - problem solved. Later C++ standards some such cases defined behaviour - that does not affect C, or introduce new pitfalls to either C or C++. At most, it makes previously undefined code into defined code - that will either fix the broken code or leave it broken. It will not break code that was previously working. If you are interested, the reason why these things are now defined in C++ is not because anyone would ever /want/ to write "i = i++ + ++i;". It is merely a side-effect of making certain other orders defined, where they /are/ useful. In particular, people have assumed that expressions like "cout << ++i << ++i;" are fully defined - in fact their orders were not. But compilers helpfully /did/ follow the order that programmers expected, and the standards have merely been updated to codify existing practice. > > Do you have any comment about the previous point about > /some/ compilers apparently /choosing/ non-standard > expression grammars? That seems remarkable to me. > As far as I can see, the difference for C is merely which error message the compiler will give depending on the way it interprets the expression. If it follows the C grammar rules for how a mixture of ? and = is to be interpreted, the result cannot be parsed and is therefore an error. If it follows the C++ grammar rules (which is the non-standard C compiler behaviour mentioned), the result can be parsed but is a constraint violation (a bit like writing "5 = a;"), and is therefore an error. I don't see a significant practical difference here. (There are plenty of other cases where some C compilers get the details of the standards wrong - but unless you are talking about really poor quality compilers, these will very rarely be seen in real-world code.) > >>> The ability to break a compiler's legitimate optimisations >>> by "casting away constness and volatility" (IIRC that took >>> several years of committee deliberation as to whether >>> it was required or forbidden behaviour!) >> >> "casting away constness and volatility" means writing code that >> explicitly tells >> the compiler "I know better than you do here, and I know it is safe to >> break >> rules about the code". Either that is true, and it lets you write the >> code you >> want, or it is wrong and you've made a mistake - as you can do in all >> languages. > > That is problematic when a library is compiled and optimised > assuming that the const statements are correct, and later on > someone else in a different company uses that library in a > way which violates those assumptions. No, I cannot see any problem here. If a library exports some constant data, then it is absolutely fine that the library is compiled and optimised on the assumption that the data never changes. If user code casts away constness and tried to change that data, the user code is clearly wrong. It is wrong in the same way that code passing -1 to a square root function is wrong, or code that calls a sin() function but is expecting to get the results of cos(). > > In those circumstances the user probably doesn't know better. > If the user does not know that he should not be changing data that is specified to be constant, then the user is not qualified for the job as programmer. > >>> And of course, the amusing C++ FQA. >> >> Have you read it? It is mostly misunderstandings, repetitions, outdated >> information, or completely unrealistic code. There are a few good >> points in it, >> but you have to work hard to find them. > > Indeed. But not all of the points can be "wished away"; many > a truth is spoken in jest. > The FQA is not particularly funny or truthful. (I have read it, as well as the original C++ FAQ - have you?). C++ certainly has plenty of flaws - it is a /big/ language. Some of these flaws get fixed over time in newer standards, others remain, and yet more get introduced. And of course there is plenty that is a matter of taste or style. But wild exaggeration of the problems is no more helpful than any claim that the language is perfect. <https://gist.github.com/klmr/5423873> > >>> All of which makes the simplicity of Forth seem appealing :) >> >> C is mostly simple and clear (if well written). C++ is a much bigger >> and more >> complex language - it has greater scope for writing good code, but >> also greater >> scope for making a mess. Simplicity of a language is not necessarily >> a good >> thing any more than complexity is - you don't get much simpler than a >> Turing >> machine, but I would not want to use it for application programming! > > I completely agree :) > > The major problem with C/C++ is that it can't make up its > mind whether it wants to be simple low-level and near to > the silicon, or an expressive high-level general purpose > applications language. Either would be valid, but in > trying to be both it misses both targets. One of the major problems with C/C++ is that there is no such language - but a lot of people seem to think there is. A lot of people find C++ works fine for one or both targets. It is, I think, the only language that covers such a wide range. But it is not a /simple/ low-level language - it is a big language, whether you use it for low-level tasks or high-level tasks. There is, however, no need to use /all/ of C++. If you are writing PC code, you will use the standard library a lot - you will use containers, strings, etc. But you don't use them on low-level code. Different parts of C++ are better suited for different needs. C, on the other hand, is not well suited for higher level work at all. There was a time when it was one of the better choices, because there were so few alternatives. But not now. > > Fortunately the marketplace has decided that in most cases > C/C++ isn't "the best" general purpose application language; > Java, Python and similar are the future there. Most of my embedded programming is in C, with a small (but increasing) part C++. Most of my PC programming is in Python.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 16:28 +0200 |
| Message-ID | <oibb70$gmq$1@dont-email.me> |
| In reply to | #26881 |
On 20/06/17 15:09, Dimiter_Popoff wrote: <snip> > What I see from where I stand is that C as a language - not as > a compiler, toolchain quality etc. - costs a lot more work to > the programmer than needed. You have given absolutely /no/ indication in the slightest as to why that might be the case, or why you might think so. What do you mean by this? Can you give examples? > One of the reasons for that is the > fact that the programmer has to delegate to the toolchain a lot > of trivial "no brainer" work and _this_ costs a significant, at > times a prohibitive, effort. Again, this makes no sense and is contrary to common experience. What makes you think that it is more productive for the programmer to do trivial no-brainer work than to let the tools do it? > How do I make my point to people > who have never been really fluent in a lower level language > which does not have the ugliness of a poor underlying model etc... > A lost cause I guess. I have programmed in assembly for a dozen or more architectures - when I started my job, it was the language of choice for small microcontrollers. In fact, when I learned assembly, I even had to hand assembly the instructions to machine code on paper. So assume that I am fluent in low level languages, and try to explain. I think the real challenge lies in that you don't really know how C works or how it is used. (As with your posts, this is not an insult in any way.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 12:58 +0200 |
| Message-ID | <oiauuj$5hv$2@dont-email.me> |
| In reply to | #26871 |
On 20/06/17 12:25, Tom Gardner wrote: > I can only easily deal with three numbers: 0, 1, many :) > All other numbers are a pain in the ass and I'm more > than happy to delegate them to a tool. There are three sorts of people in this world - those that can count, and those that can't.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 12:57 +0200 |
| Message-ID | <oiaurr$5hv$1@dont-email.me> |
| In reply to | #26870 |
On 20/06/17 11:36, dp wrote:
> On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote:
>> On 20/06/17 09:25, Dimiter_Popoff wrote:
>>> On 20.6.2017 г. 07:12, rickman wrote:
>>>> ....
>>>>
>>>> So you think for a language to be modern it has to have hard coded data
>>>> sizes?
>>
>> If you are going to use it for low-level programming and embedded
>> development, then yes.
>
> No. If you don't know which datum of which size and type is you are
> not up to programming.
The reason I know exactly which size a datum is, is because the type has
a fixed size!
If I need to know that "x" has 32 bits, I make sure of that fact by
declaring "x" as a "uint32_t" or "int32_t" in C. I can do that,
precisely because C supports such hard coded data sizes.
In a language like Forth, or pre-C99 C, you can't do that portably. An
"int" might be 16-bit, or maybe 32-bit, or maybe something weird - the
same applies to a Forth "cell". You need pre-processor directives,
conditional compilation, implementation-specific code, etc., in order to
know for sure what sizes you are using.
> Delegating to the tool to track that means
> only more work for the programmer, sometimes a lot more while tracking
> what the tool got wrong _this_ time.
Are you seriously suggesting that sometimes compilers will get the sizes
wrong? That if I ask a C compiler for an "int64_t", sometimes it will
give me a different size?
Or are you talking about more complex types? If I define a struct that
I know should match an external definition (hardware registers, telegram
format, etc.) of a particular size, I can write:
typedef struct {
uint16_t x;
uint8_t ys[6];
...
} reg_t;
static_assert(sizeof(reg_t) == 24, "Checking size of reg_t struct");
The /compiler/ does the counting and the checking. It does so easily
and reliably, handles long and complicated structures, is portable
across processors of difference sizes, and will always give a clear and
unmistakeably compile-time error message if there is a problem.
>
>>> Programmers should use their ability to count not just for stack levels,
>>> it is a lot more effective than working to delegate the counting of
>>> this and that to a tool which is a lot less intelligent than the
>>> programmer. Just let the tool do the heavy lifting exercises, counting
>>> is not one of these.
>>>
>>
>> Counting is one of the tasks I expect a computer - and therefore a
>> programming language and a toolchain - to do well. I expect the tool to
>> do the menial stuff and let the programmer get on with the thinking.
>
> If "counting" is too much of a workload is too much for a person he
> is not in the right job as a programmer (hopefully "counting" is not
> taken literally here, it means more "counting up to ten").
> Delegating simple tasks to the tool makes life harder, not easier,
> as I said above. Often a lot harder.
You said it above - but you were wrong (IMHO).
>
> Controlled types, sizes etc. by the machine are meant for the user,
> not for the programmer. They are supposed to make these work, this *is*
> their job. Pretty much like a meal is supposed to be served nicely
> arranged on a plate for the consumer; however for the cook the
> ingredients are a lot more convenient in a raw form.
>
Think of having the compiler check sizes and do "counting" as like the
thermostat and timer on the oven. The cook (or programmer) decides on
the temperature and timing he wants, but the oven handles the boring bit
of turning the elements on and off to get the right temperature, and
warns the cook when the timer is done.
> Dimiter
>
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-06-20 14:19 +0300 |
| Message-ID | <oib04s$9q3$1@dont-email.me> |
| In reply to | #26874 |
On 20.6.2017 г. 13:57, David Brown wrote: > On 20/06/17 11:36, dp wrote: >> On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: >>> On 20/06/17 09:25, Dimiter_Popoff wrote: >>>> On 20.6.2017 г. 07:12, rickman wrote: >>>>> .... >>>>> >>>>> So you think for a language to be modern it has to have hard coded data >>>>> sizes? >>> >>> If you are going to use it for low-level programming and embedded >>> development, then yes. >> >> No. If you don't know which datum of which size and type is you are >> not up to programming. > > The reason I know exactly which size a datum is, is because the type has > a fixed size! > > If I need to know that "x" has 32 bits, I make sure of that fact by > declaring "x" as a "uint32_t" or "int32_t" in C. I can do that, > precisely because C supports such hard coded data sizes. > > In a language like Forth, or pre-C99 C, you can't do that portably. An > "int" might be 16-bit, or maybe 32-bit, or maybe something weird - the > same applies to a Forth "cell". You need pre-processor directives, > conditional compilation, implementation-specific code, etc., in order to > know for sure what sizes you are using. So C has improved. But this is only about C overcoming one of its shortcomings by adding more complexity for the programmer to deal with, which is exactly my point. You need to know what your compiler does with your data type only if you have to rely on it to deal with it instead of just dealing with it yourself when you know what it is anyway. > >> Delegating to the tool to track that means >> only more work for the programmer, sometimes a lot more while tracking >> what the tool got wrong _this_ time. > > Are you seriously suggesting that sometimes compilers will get the sizes > wrong? That if I ask a C compiler for an "int64_t", sometimes it will > give me a different size? Are you seriously suggesting that you have not spent well over half of your programming time figuring out what the compiler expects from you. >.... >> >> Controlled types, sizes etc. by the machine are meant for the user, >> not for the programmer. They are supposed to make these work, this *is* >> their job. Pretty much like a meal is supposed to be served nicely >> arranged on a plate for the consumer; however for the cook the >> ingredients are a lot more convenient in a raw form. >> > > Think of having the compiler check sizes and do "counting" as like the > thermostat and timer on the oven. The cook (or programmer) decides on > the temperature and timing he wants, but the oven handles the boring bit > of turning the elements on and off to get the right temperature, and > warns the cook when the timer is done. Then a month later the menu changes and you have to set the temperature to the one for the meal you did last month. Oops, what was it? Spend another week rediscovering that. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 16:19 +0200 |
| Message-ID | <oibam5$eru$1@dont-email.me> |
| In reply to | #26876 |
On 20/06/17 13:19, Dimiter_Popoff wrote: > On 20.6.2017 г. 13:57, David Brown wrote: >> On 20/06/17 11:36, dp wrote: >>> On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote: >>>> On 20/06/17 09:25, Dimiter_Popoff wrote: >>>>> On 20.6.2017 г. 07:12, rickman wrote: >>>>>> .... >>>>>> >>>>>> So you think for a language to be modern it has to have hard coded >>>>>> data >>>>>> sizes? >>>> >>>> If you are going to use it for low-level programming and embedded >>>> development, then yes. >>> >>> No. If you don't know which datum of which size and type is you are >>> not up to programming. >> >> The reason I know exactly which size a datum is, is because the type has >> a fixed size! >> >> If I need to know that "x" has 32 bits, I make sure of that fact by >> declaring "x" as a "uint32_t" or "int32_t" in C. I can do that, >> precisely because C supports such hard coded data sizes. >> >> In a language like Forth, or pre-C99 C, you can't do that portably. An >> "int" might be 16-bit, or maybe 32-bit, or maybe something weird - the >> same applies to a Forth "cell". You need pre-processor directives, >> conditional compilation, implementation-specific code, etc., in order to >> know for sure what sizes you are using. > > So C has improved. We are talking about a change in the language nearly 20 years ago... And even before that, it was normal to have a header with things like: typedef short int i16; typedef unsigned long int u32; etc. Pre C99, you had to make such headers yourself, adapt them to fit a given implementation, and there was no standardisation of the names. But it was a job you did once for each platform you used. Because C is a typed language, you can make the definitions of the types depend on the platform, but the code using the types is then platform independent. > But this is only about C overcoming one of its > shortcomings by adding more complexity for the programmer to deal > with, which is exactly my point. /Where/ is this complexity you talk about? I cannot understand what you mean here, and why you think there is some extra effort. If I want a 32-bit variable, I make an int32_t or a uint32_t (signed or unsigned). I make the choice of the characteristics I need for the data, and write it clearly, simply, and quickly in the source code. There is no effort involved. > You need to know what your compiler > does with your data type only if you have to rely on it to deal with > it instead of just dealing with it yourself when you know what it > is anyway. That makes no sense whatsoever. How do you "deal with it yourself"? You write source code, the compiler compiles it to machine code. You are relying on the compiler, just like when you write in assembly code you rely on the assembler. You can get a difference when you don't care about the details. If I write "x * 5", I (usually) don't care if the compiler implements that with a multiply instruction, or shift and add instructions, or a "load effective address" instruction with odd addressing modes, or if it has figured out that "x" is always 3 at this point in the code, and can use 15 directly. And when I /do/ care about the details, such as the size of a piece of data, /then/ I write explicitly what I want. That, if anything, is "dealing with it myself". > >> >>> Delegating to the tool to track that means >>> only more work for the programmer, sometimes a lot more while tracking >>> what the tool got wrong _this_ time. >> >> Are you seriously suggesting that sometimes compilers will get the sizes >> wrong? That if I ask a C compiler for an "int64_t", sometimes it will >> give me a different size? > > Are you seriously suggesting that you have not spent well over half > of your programming time figuring out what the compiler expects from > you. The compiler expects me to write valid C code. Nothing more, nothing less. I have spent time learning how to write valid C code - but no, that has not taken half my programming career. > >> .... >>> >>> Controlled types, sizes etc. by the machine are meant for the user, >>> not for the programmer. They are supposed to make these work, this *is* >>> their job. Pretty much like a meal is supposed to be served nicely >>> arranged on a plate for the consumer; however for the cook the >>> ingredients are a lot more convenient in a raw form. >>> >> >> Think of having the compiler check sizes and do "counting" as like the >> thermostat and timer on the oven. The cook (or programmer) decides on >> the temperature and timing he wants, but the oven handles the boring bit >> of turning the elements on and off to get the right temperature, and >> warns the cook when the timer is done. > > Then a month later the menu changes and you have to set the temperature > to the one for the meal you did last month. Oops, what was it? > Spend another week rediscovering that. > What on earth does that mean? When a cook sets the temperature on his oven thermostat, that does not somehow suck the information out his brain and erase it from all his recipe books!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-20 12:12 +0000 |
| Message-ID | <2017Jun20.141213@mips.complang.tuwien.ac.at> |
| In reply to | #26853 |
David Brown <david.brown@hesbynett.no> writes:
>On 19/06/17 16:44, Anton Ertl wrote:
>> A static checker might say that the DROP and the - access a value that
>> is not present in the stack effect, so they would be a little more
>> precise at pinpointing the problem, but stack depth issues are easy
>> enough that nobody found it worthwhile to write such a checker yet.
>
>I would be much happier to see the language supporting such static
>checks in some way (not as comments, but as part of the language), and
>tools doing the checking. Spotting such errors during testing is better
>than spotting them when running the program, but spotting them during
>compilation is far better.
Why would that be? I can see that it's far better for programmers who
don't test their programs, but what is the advantage for programmers
who test their programs?
> (Better still is spotting them while editing
>- IDEs for C usually do a fair amount of checking while you write the code.)
And I would especially hate it if an IDE is distracting me by nagging
me about minor details while I am focusing on something else.
>> No! I have had lots of portability problems for C code when porting
>> between 32-bit and 64-bit systems, thanks to the integer type zoo of
>> C. In Forth I have had very few such problems, thanks to the fact
>> that we only have cells and occasionally double-cells (and when you
>> get a double-cell program right on 32-bit systems, it also works on
>> 64-bit systems). If you want a FLOOR5 variant that works for integers
>> that don't fit in a cell, you write DFLOOR5. And if it does not fit
>> in double cells (but would fit in 64 bits), you probably have the
>> wrong machine for what you are trying to do. C did not acquire 64-bit
>> integer types until 32-bit machines were mainstream.
>>
>
>And there you have illustrated my point, to some extent - C has
>progressed as a language, to include new features for more modern
>systems, such as support for 64-bit types. Now I can use a C compiler
>for an 8-bit microcontroller and have 64-bit datatypes. (OK, not all
>implementations have such support - but that is a quality of
>implementation issue, not a language failure.)
If the language does not require the 64-bit types, you can hardly
claim them as a language feature.
Anyway, if 64-bit integers were needed on 16-bit-cell systems, we
would add them to Forth. But in discussions about this subject, the
consensus emerged that we do not need them (at least not for
computations).
By contrast, Gforth and PFE have provided 128-bit integers on 64-bit
systems since 1995, something that C compilers have not supported for
quite a while after that. And once GCC started supporting it, it was
quite buggy; I guess the static-checking-encouraged lack of testing
was at work here.
>And it is perfectly possible to write C code that is portable across
>32-bit and 64-bit systems
There is a difference between "it is possible" and "it happens". My
experience is that, in C, if you have tested a program only on 32-bit
systems, it will likely not work on 64-bit systems; in Forth, it
likely will.
>On the other hand, you don't seem to be able to write a FLOOR5
>definition that will handle 32-bit values efficiently on both 16-bit
>cell systems and 32-bit cell systems.
Tough luck. Why would I need a double FLOOR5 on a 16-bit platform?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 16:48 +0200 |
| Message-ID | <oibcdj$ktv$1@dont-email.me> |
| In reply to | #26879 |
On 20/06/17 14:12, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 19/06/17 16:44, Anton Ertl wrote: >>> A static checker might say that the DROP and the - access a value that >>> is not present in the stack effect, so they would be a little more >>> precise at pinpointing the problem, but stack depth issues are easy >>> enough that nobody found it worthwhile to write such a checker yet. >> >> I would be much happier to see the language supporting such static >> checks in some way (not as comments, but as part of the language), and >> tools doing the checking. Spotting such errors during testing is better >> than spotting them when running the program, but spotting them during >> compilation is far better. > > Why would that be? I can see that it's far better for programmers who > don't test their programs, but what is the advantage for programmers > who test their programs? Honestly? You can't see the advantage of spotting errors at as early a stage as possible? Why would someone bother writing test patterns to catch possible errors that the tools can see automatically? That is just a waste of everyone's time, and it's easy to forget some tests. Errors of various sorts can happen when you write code. They can be everything from misunderstandings of the specifications, to small typos, to stylistic errors (which don't affect the running code, but can affect maintainability and lead to higher risk of errors in the future), to unwarranted assumptions about how the code is used. Producing a correct program involves a range of methods for avoiding errors, or detecting them as early as possible. Testing (of many different kinds) is /part/ of that - but it is most certainly not sufficient. It is /always/ cheaper and more productive to spot errors at an earlier stage than at a later stage - and detecting them at compilation time is earlier than detecting them at unit test time or system test time. > >> (Better still is spotting them while editing >> - IDEs for C usually do a fair amount of checking while you write the code.) > > And I would especially hate it if an IDE is distracting me by nagging > me about minor details while I am focusing on something else. Incorrect code is not a minor detail. > >>> No! I have had lots of portability problems for C code when porting >>> between 32-bit and 64-bit systems, thanks to the integer type zoo of >>> C. In Forth I have had very few such problems, thanks to the fact >>> that we only have cells and occasionally double-cells (and when you >>> get a double-cell program right on 32-bit systems, it also works on >>> 64-bit systems). If you want a FLOOR5 variant that works for integers >>> that don't fit in a cell, you write DFLOOR5. And if it does not fit >>> in double cells (but would fit in 64 bits), you probably have the >>> wrong machine for what you are trying to do. C did not acquire 64-bit >>> integer types until 32-bit machines were mainstream. >>> >> >> And there you have illustrated my point, to some extent - C has >> progressed as a language, to include new features for more modern >> systems, such as support for 64-bit types. Now I can use a C compiler >> for an 8-bit microcontroller and have 64-bit datatypes. (OK, not all >> implementations have such support - but that is a quality of >> implementation issue, not a language failure.) > > If the language does not require the 64-bit types, you can hardly > claim them as a language feature. C /does/ require them (in C99), and they /are/ a language feature. (Technically, C requires an integer type that is at least 64 bits, but for most practical purposes, real implementations have exactly 64-bit types.) There are C compilers that don't support all of C99. And I have used 64-bit integers on an 8-bit microcontroller. It is a rare requirement, certainly, but not inconceivable. > > Anyway, if 64-bit integers were needed on 16-bit-cell systems, we > would add them to Forth. But in discussions about this subject, the > consensus emerged that we do not need them (at least not for > computations). > > By contrast, Gforth and PFE have provided 128-bit integers on 64-bit > systems since 1995, something that C compilers have not supported for > quite a while after that. And once GCC started supporting it, it was > quite buggy; I guess the static-checking-encouraged lack of testing > was at work here. Static checking is an addition to testing, not an alternative. > >> And it is perfectly possible to write C code that is portable across >> 32-bit and 64-bit systems > > There is a difference between "it is possible" and "it happens". My > experience is that, in C, if you have tested a program only on 32-bit > systems, it will likely not work on 64-bit systems; in Forth, it > likely will. I don't see a way to write portable code that works with known sizes of data in Forth. All I have seen so far is that you can use single cells for 16-bit data, and double cells for 32-bit data. This means if you want to use 32-bit values, your choice is between broken code on 16-bit systems or inefficient code on 32-bit systems. (And you can only tell if it is broken on 16-bit systems if you have remembered to include a test case with larger data values.) I work on embedded systems. I need to be able to access memory with /specific/ sizes. I need to be able to make structures with /specific/ sizes. Can you show me how this is possible in Forth, in a clear, simple and portable manner? > >> On the other hand, you don't seem to be able to write a FLOOR5 >> definition that will handle 32-bit values efficiently on both 16-bit >> cell systems and 32-bit cell systems. > > Tough luck. Why would I need a double FLOOR5 on a 16-bit platform? > That is not for you to worry about. Think of me as a customer asking for a piece of code written in Forth. I want a FLOOR5 function that handles 32-bit values, works correctly on 16-bit and 32-bit cell systems, and is efficient on both sizes of system. Can it be done?
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-06-20 21:16 +0100 |
| Message-ID | <oibvj4$pnb$1@dont-email.me> |
| In reply to | #26885 |
On 20/06/2017 15:48, David Brown wrote: > I work on embedded systems. I need to be able to access memory with > /specific/ sizes. I need to be able to make structures with/specific/ > sizes. > > Can you show me how this is possible in Forth, in a clear, simple and > portable manner? > >>> On the other hand, you don't seem to be able to write a FLOOR5 >>> definition that will handle 32-bit values efficiently on both 16-bit >>> cell systems and 32-bit cell systems. >> Tough luck. Why would I need a double FLOOR5 on a 16-bit platform? >> > That is not for you to worry about. Think of me as a customer asking > for a piece of code written in Forth. I want a FLOOR5 function that > handles 32-bit values, works correctly on 16-bit and 32-bit cell > systems, and is efficient on both sizes of system. Can it be done? > > Yes, but you may not like it - use conditional compilation 0 invert 65535 u> [if] : floor5 ( n1 -- n2 ) 1- 5 max ; \ 32 bit cells [else] : floor5 ( d1 -- d2 ) 1. d- 5. dmax ; \ 16 bit cells [then] -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-20 23:15 +0200 |
| Message-ID | <oic332$60v$1@dont-email.me> |
| In reply to | #26888 |
On 20/06/17 22:16, Gerry Jackson wrote:
> On 20/06/2017 15:48, David Brown wrote:
>> I work on embedded systems. I need to be able to access memory with
>> /specific/ sizes. I need to be able to make structures with/specific/
>> sizes.
>>
>> Can you show me how this is possible in Forth, in a clear, simple and
>> portable manner?
>>
>>>> On the other hand, you don't seem to be able to write a FLOOR5
>>>> definition that will handle 32-bit values efficiently on both 16-bit
>>>> cell systems and 32-bit cell systems.
>>> Tough luck. Why would I need a double FLOOR5 on a 16-bit platform?
>>>
>> That is not for you to worry about. Think of me as a customer asking
>> for a piece of code written in Forth. I want a FLOOR5 function that
>> handles 32-bit values, works correctly on 16-bit and 32-bit cell
>> systems, and is efficient on both sizes of system. Can it be done?
>>
>>
>
> Yes, but you may not like it - use conditional compilation
>
> 0 invert 65535 u> [if]
> : floor5 ( n1 -- n2 ) 1- 5 max ; \ 32 bit cells
> [else]
> : floor5 ( d1 -- d2 ) 1. d- 5. dmax ; \ 16 bit cells
> [then]
>
Conditional compilation is fine as a solution. But supposing you wanted
a number of functions that were all 32-bit (let's say, floor6, floor7,
and floor8 due to a lack of imagination). Is there any way to have a
single conditional bit, and then use the features in other words? (Like
defining the type "int32_t" once in C, and using it thereafter.) My
stab at a solution would be:
0 invert 65535 u> [if] \ 32 bit cells
: -32 ( n1, n2 -- n3 ) - ;
: max32 ( n1, n2 -- n3) max ;
: to32 ( n1 -- n1 ) ;
[else] \ 16 bit cells
: -32 ( d1, d2 -- d3 ) d- ;
: max32 ( d1, d2 -- d3) dmax ;
: to32 ( n1 -- d1 ) S>D ;
[then]
: floor5 ( 32x1 -- 32x2 ) 1 to32 -32 5 to32 max32 ;
: floor6 ( 32x1 -- 32x2 ) 1 to32 -32 6 to32 max32 ;
etc.
The equivalent C (without the C99 sized integers) is:
#include <limits.h>
#if UINT_MAX == 65535
typedef long int i32;
#else
typedef int i32;
#endif
i32 floor5(32 v) {
return (v < 6) ? 5 : (v - 1);
}
i32 floor6(32 v) {
return (v < 7) ? 6 : (v - 1);
}
(That is, like your Forth, assuming that you either have 16-bit cells /
ints and 32-bit double cells / long ints, or 32-bit cells / ints.)
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-06-21 07:30 +0100 |
| Message-ID | <oid3jf$p54$1@dont-email.me> |
| In reply to | #26890 |
On 20/06/2017 22:15, David Brown wrote:
> On 20/06/17 22:16, Gerry Jackson wrote:
>> On 20/06/2017 15:48, David Brown wrote:
>>> I work on embedded systems. I need to be able to access memory with
>>> /specific/ sizes. I need to be able to make structures with/specific/
>>> sizes.
>>>
>>> Can you show me how this is possible in Forth, in a clear, simple and
>>> portable manner?
>>>
>>>>> On the other hand, you don't seem to be able to write a FLOOR5
>>>>> definition that will handle 32-bit values efficiently on both 16-bit
>>>>> cell systems and 32-bit cell systems.
>>>> Tough luck. Why would I need a double FLOOR5 on a 16-bit platform?
>>>>
>>> That is not for you to worry about. Think of me as a customer asking
>>> for a piece of code written in Forth. I want a FLOOR5 function that
>>> handles 32-bit values, works correctly on 16-bit and 32-bit cell
>>> systems, and is efficient on both sizes of system. Can it be done?
>>>
>>>
>>
>> Yes, but you may not like it - use conditional compilation
>>
>> 0 invert 65535 u> [if]
>> : floor5 ( n1 -- n2 ) 1- 5 max ; \ 32 bit cells
>> [else]
>> : floor5 ( d1 -- d2 ) 1. d- 5. dmax ; \ 16 bit cells
>> [then]
>>
>
> Conditional compilation is fine as a solution. But supposing you wanted
> a number of functions that were all 32-bit (let's say, floor6, floor7,
> and floor8 due to a lack of imagination). Is there any way to have a
> single conditional bit, and then use the features in other words? (Like
> defining the type "int32_t" once in C, and using it thereafter.) My
> stab at a solution would be:
>
> 0 invert 65535 u> [if] \ 32 bit cells
> : -32 ( n1, n2 -- n3 ) - ;
> : max32 ( n1, n2 -- n3) max ;
> : to32 ( n1 -- n1 ) ;
> [else] \ 16 bit cells
> : -32 ( d1, d2 -- d3 ) d- ;
> : max32 ( d1, d2 -- d3) dmax ;
> : to32 ( n1 -- d1 ) S>D ;
> [then]
>
>
> : floor5 ( 32x1 -- 32x2 ) 1 to32 -32 5 to32 max32 ;
> : floor6 ( 32x1 -- 32x2 ) 1 to32 -32 6 to32 max32 ;
> etc.
>
Yes that's a way to achieve it. However, for performance, I would use
POSTPONE and IMMEDIATE to compile the small functions inline e.g.
0 invert 65535 u> [if] \ 32 bit cells
: -32 ( n1, n2 -- n3 ) postpone - ; immediate
: max32 ( n1, n2 -- n3) postpone max ; immediate
: to32 ( n1 -- n1 ) ; immediate
[else] \ 16 bit cells
: -32 ( d1, d2 -- d3 ) postpone d- ; immediate
: max32 ( d1, d2 -- d3) postpone dmax ; immediate
: to32 ( n1 -- d1 ) postpone S>D ; immediate
[then]
Then, for example, TO32 for 32 bit cells compiles nothing in FLOOR5 etc.
But, as an aside, a warning, -32 is treated by Forth as an integer so
after the above definitions you couldn't ever use -32 as a literal in
another definition as it would compile a -. Better to call it, say, SUB32
With this technique you could also do:
0 invert 65535 u> constant 32bits
: -32 32bits if postpone - else postpone d- then ; immediate
and so on. This would result in the same compiled code for FLOOR5 etc
with less source code noise. At the cost of more compiled code of course
as -32 etc are bigger. But this wouldn't matter if you were cross
compiling on a host for a target system.
Another alternative is to factor out the conditional part:
0 invert 65535 u> constant 32bits
: postpone-it ( xt1 xt2 -- ) \ xt1 is for 32 bit cells, xt2 for 16 bits
32bits if drop else nip then compile,
;
: -32 ['] - ['] d- postpone-it ; immediate
: max32 ['] max ['] dmax postpone-it ; immediate
etc
but whether that is worthwhile depends on how many of these definitions
there are.
--
Gerry
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web