On 6/21/17 9:05 AM, rickman wrote:
> David Brown wrote on 6/21/2017 1:29 PM:
...
>> That is interesting to know, thank you. I have assumed that the tests
>> being
>> discussed were run-time tests.
>
> What exactly is the difference? You compile a Forth program essentially
> by "running" the source code. So you run the code that defines new
> words and run the code that tests them.
It's quite easy to write code that compiles perfectly but the logic is
wrong. Most applications require extensive testing even though they
compile without error.
>> Do the compile time tests work correctly even for cross-compiled systems,
>> where there may be different capabilities (say, different sizes for
>> cells)
>> from the host?
>
> You can use a PC as a compiler for
> embedded Forth, but it is also very common to run Forth on the target
> with the PC just being for file storage and editing.
You write the application to run on the target, respecting its
facilities and requirements. Cross-compilers accommodate these things,
and the good ones support an umbilical to help you test your program
interactively just as though it were running on the host.
>>> If you are going to forget tests you are doomed. Every piece of code
>>> should be written to a set of requirements, each of which must be
>>> verified, usually by testing. Forget a test and you have unverified
>>> code.
Correct. An the important tests are the ones that test the functionality
of the application, not trivial compile-time issues.
>
...
>>>> 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.
Compile-time checking happens, but cannot check the kinds of logical
errors that thorough functional testing can test. The kinds of
compile-time checks that Forth generally does not do (e.g. type
mismatches) are, in my experience, easily caught is preliminary
functional testing, and not major issues.
>>>> Incorrect code is not a minor detail.
No, but the serious errors aren't detectable by compilers, in my experience.
>>> I've never seen a C editor that would catch anything more complex than
>>> mismatched parentheses. Do editors look for missing variable
>>> declarations
>>> now?
>>>
>>
>> Yes.
So does Forth.
...
>>>>>> 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.)
>>>
>>> Again, you don't understand Forth. You use single cells or double
>>> cells.
>>> Forth does not specify the cell size just as C does not specify the size
>>> of an integer.
In practice, dealing with chars, cells, and double-cells is quite
practical. FORTH, Inc. has a fairly vast amount of code that runs
without change on 8- 16- and 32-bit processors. As our main business is
with microcontrollers, we have not yet felt pressure to address 64-bit
systems yet, but do not anticipate serious problems there.
>> I understand that fine. And in a lot of C programming, it is a big pain
>> that the language does not specify the size of an int - thus
>> size-specific
>> types are used (standardised in C99, but used long before that). So
>> with C
>> you have the choice to use efficient integers whose size depends on the
>> target, or integers whose size is known and fixed.
>>>
>>>> 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.
Open Firmware addressed that by adding some data types with specific
bit-widths. It was straightforward to do. But in the embedded work I've
been involved with we haven't really found a need to do that.
>>>> Can you show me how this is possible in Forth, in a clear, simple and
>>>> portable manner?
>>>
>>> Forth has cells (a word) and chars (a byte). I don't find it to be a
>>> problem, but then I don't typically jump back and forth between 32
>>> and 16
>>> bit processors. What 16 bit processors do you actually use?
>>
>> msp430 and AVR (the AVR is 8-bit, but C "ints" and Forth cells are
>> 16-bit).
We see both of those a lot. We use a 16-bit cell on those, and have
8-bit operators in addition.
>> It looks like the answer is simply that Forth does not support convenient
>> portable programming across different cell sizes in code where you
>> need to
>> be accurate about your data sizes. It is /possible/ (see Gerry's
>> answers),
>> but ugly and inconvenient.
>
> Forth programmers often develop what they need. I don't see many
> discussing the issues of porting between AVR and ARM. I guess they
> don't often need that. Am I wrong? Mr. Pelc would be one to ask. He
> has developed Forth for a very wide range of systems with many different
> word sizes from 8051 to Pentiums. Same for Forth, Inc.
Over 90% of the code we run on AVRs and ARMs is portable.
>> OK, that is an answer. It is not the only language with limitations
>> like that.
>>
>> (It is quite possible that particular implementations of Forth, targeted
>> specifically for embedded systems and cross-compilation, have
>> extensions or
>> additional word sets designed to make it easy to get exact sized
>> types, to
>> access memory in specific sized units, etc.)
>
> See above.
>
>
>>>>>> 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?
There have been times when we have used doubles on 32-bit systems for
portability to/from 16-bit systems. The most prominent example is in the
output number conversion words, <# # #S #> etc., which are defined to
work on doubles. Open Firmware made special cell-wise equivalents (with
different names, of course), as that standard did not support smaller
cell sizes. It's a perfectly reasonable accommodation, and trivial to
implement.
>>>> 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?
>>>
>>> No one has customers asking for simple functions.
Yes, if that's the requirement we'd probably use doubles, depending on
other requirements of the project. The added inefficiency is trivial. In
the 90's, FORTH, Inc. and MPE developed an extensive amount of code for
smart card terminals using the full range of processors, from 8051's to
x86's. For that project we standardized on a 32-bit cell size for a
variety of reasons, and managed to write primitives on the low-end
processors that were quite civilized in performance, even doing Triple
DES and RSA. Our terminals ran quite a lot faster than the current
Java-based ones in use here in the US.
Cheers,
Elizabeth
--
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA