Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32204
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Purpose of the ANS Forth Standard |
| Date | 2014-07-04 14:35 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <lp6s5d$iu1$1@dont-email.me> (permalink) |
| References | (1 earlier) <8049738e-5524-4eab-8950-89bb392b1033@googlegroups.com> <lp4611$r3a$1@dont-email.me> <8f843809-e144-44e9-92ae-a607787d18a6@googlegroups.com> <lp4glt$8lr$1@dont-email.me> <e2532bc3-b1be-4b87-a27f-0c2e6f610c2e@googlegroups.com> |
On 7/3/2014 6:23 PM, bruce.mcfarling@gmail.com wrote: > On Thursday, July 3, 2014 5:07:04 PM UTC-4, rickman wrote: >> I'm not sure why you can't code for all cell widths. I suppose there is >> a problem of counting range, but otherwise it is not hard to make no >> assumption about cell width and so work equally well on any machine. > > I think you can. You can easily define a word to find out cell-bits, which then gives au-bits and char-bits as computed constants. > > You need to distinguish between: > * processes that require a certain minimum size > * processes where process constraints depend on size, and > * processes that are defined differently above and below a threshold size > * processes that require a specific bit size > > .... and you need test systems that represent both smaller and bigger cell size environments to test on. If that is a 32bit or 64bit main development platform and a 16bit portability test platform, that can also do double duty in terms of exercising your cross-platform provisions. I like hForth86 EXE model for that, since the 64K data, 64K code and 64K namespace (and 8K special system data for 200K altogether) means it runs into fewer binding memory constraints making it easier to focus on the portability of the code. And its pretty easy to find a DosBox to run it in, whatever development system I'm using (if using my old netbook, its just "double click", since its old enough it still automatically uses a built-in dos box). > > * 1. processes that require a certain minimum size ~ test and on failing print a warning and stop loading. > > * 2. processes with constraints that depend on cell size, compute the constraint for based on actual cell size that its running on and save the result in constraint constants. And the source should make more sense than magic numbers. > > * 3. processes that are defined differently above and below a threshold size, program for one and port for the other. If you can encapsulate the words that depend on cell size in distinct files, so much the better, as you can test for cell size and use that to conditionally include the correct source. > > * 4. processes that require a specific bit size, code distinct memory access for that bit size (the Forth200x names can be used), and for most stack operations you can treat equal to or bigger than that size and smaller than that size as a case of (3). > > Porting for different cell-sizes is easier than porting for different char-sizes, since there's a number of 16bit test beds to choose from. I try to use CHARS and CHAR+ but without a bigchar testbed, all I could really do is: > > char-bits au-bits <> [IF] > .\ > .\ Note that this has not been tested on big char systems > .\ ... some additional testing & bugfixes may be required. > [THEN] I guess this is not what I was thinking. Trying to code N bit data in a way that will work on 64, 36, 32, 16, 12 and 8 bit machines is just too much trouble to be worth it unless it is absolutely required. I was thinking in terms of other aspects like when data is shifted to get a given bit into a given bit position. It seems too obvious that code written for a 32 bit CPU won't run on a 16 bit machine without a large effort and won't run on an N bit machine without a HUGE effort. But what are the issues with code written for a 16 bit machine running on 32 bit hardware, other than depending on unspecified actions on overflow, etc. are there any? -- Rick
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Purpose of the ANS Forth Standard rickman <gnuarm@gmail.com> - 2014-07-02 12:18 -0400
Re: Purpose of the ANS Forth Standard bruce.mcfarling@gmail.com - 2014-07-02 10:11 -0700
Re: Purpose of the ANS Forth Standard Roger Levy <roger.levy@gmail.com> - 2014-07-03 09:33 -0700
Re: Purpose of the ANS Forth Standard Roger Levy <roger.levy@gmail.com> - 2014-07-03 09:39 -0700
Re: Purpose of the ANS Forth Standard albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-03 17:12 +0000
Re: Purpose of the ANS Forth Standard Roger Levy <roger.levy@gmail.com> - 2014-07-03 10:52 -0700
Re: Purpose of the ANS Forth Standard bruce.mcfarling@gmail.com - 2014-07-03 11:53 -0700
Re: Purpose of the ANS Forth Standard rickman <gnuarm@gmail.com> - 2014-07-03 14:05 -0400
Re: Purpose of the ANS Forth Standard Roger Levy <roger.levy@gmail.com> - 2014-07-03 11:48 -0700
Re: Purpose of the ANS Forth Standard bruce.mcfarling@gmail.com - 2014-07-03 11:55 -0700
Re: Purpose of the ANS Forth Standard rickman <gnuarm@gmail.com> - 2014-07-03 17:07 -0400
Re: Purpose of the ANS Forth Standard Roger Levy <roger.levy@gmail.com> - 2014-07-03 15:20 -0700
Re: Purpose of the ANS Forth Standard rickman <gnuarm@gmail.com> - 2014-07-03 19:29 -0400
Re: Purpose of the ANS Forth Standard bruce.mcfarling@gmail.com - 2014-07-03 15:23 -0700
Re: Purpose of the ANS Forth Standard rickman <gnuarm@gmail.com> - 2014-07-04 14:35 -0400
Re: Purpose of the ANS Forth Standard "Elizabeth D. Rather" <erather@forth.com> - 2014-07-04 09:24 -1000
Re: Purpose of the ANS Forth Standard bruce.mcfarling@gmail.com - 2014-07-04 19:32 -0700
Re: Purpose of the ANS Forth Standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-04 14:19 +0000
Re: Purpose of the ANS Forth Standard "Elizabeth D. Rather" <erather@forth.com> - 2014-07-03 14:50 -1000
csiph-web