MCU mimicking a SPI flash slave

That is interesting to know, thank you. I have assumed that the tests being discussed were run-time tests.

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?

I did not suggest that tests should be omitted - I suggested that compile-time checks are useful in addition to run-time tests. And I still think that the kind of automatic compile-time checking that is possible with a language like C is better than having to manually write tests in Forth - quite simply, you need to write fewer test cases if the toolchain can check more things automatically.

Yes.

(As a technicality, the IDE might do this sort of thing by running a program like cppcheck in the background, but it appears the same to the user.)

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.

msp430 and AVR (the AVR is 8-bit, but C "ints" and Forth cells are 16-bit).

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.

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.)

Reply to
David Brown
Loading thread data ...

You are still deeply misinformed. Surely it's up to you to do your own research rather than blather "fake news" across the interwires.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

So there is the equivalent of three 16 bit counter/timer/comparator/shifter/whatever for *each* port pin? That may not dominate the chip area, but it is going to add up fast. I'll bet it is larger than a set of fixed peripherals in low end MCUs that can be sold for $1. Just how much logic do you think is in an SPI port?

Xilinx used to say they sell you the routing and give the logic away for free. What's your point? How do FPGAs come into the cost basis of the XMOS?

The real issue is that they just can't compete in the low price end of MCUs where I feel they would be most useful. But they have their niche and I guess they aren't going anywhere soon. I wonder what it would take for the XMOS concept to be scaled up to cover more at the high end?

--

Rick C
Reply to
rickman

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.

This is at such a basic level of Forth that I find it hard to believe you have actually given Forth anything but a cursory glance.

More lack of knowledge of Forth. 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.

If you can try not to tick off Steven you can go to his web site and download a copy that you can work with. Same at Forth, Inc.

"it's easy to forget some tests."

Does that refresh your memory?

Yeah, but when run time and compile time are hard to distinguish, the advantage goes away.

You are writing applesauce about *more* tests. Which of the tests that Anton gave you were for catching the error you wrote in the code? None specifically and all in general. No extra tests needed.

I would suggest at this point you stop trying to trash Forth based on what you thought you learned and instead give Forth a real go. Come here if you have questions and I'm sure you will get plenty of help.

Oh, the only real reason I know of for not using Forth is the lack of Forth programmers for hire. Notice I said "for hire". There aren't many experts out there to bring in quickly if you have a problem. But it is not hard to train someone to use Forth, at least according to many here. The language is great and many have done lots with it.

Sounds like the territory someone here was complaining about of the false positives as code is typed in. I wonder how they keep from flagging stuff you are creating by going back and forth in code as you think?

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.

See above.

--

Rick C
Reply to
rickman

An interesting PoV, with some merit.

However, having developed in both Smalltalk (=Forth for this argument) and Java (=C for this argument), I know I am /much/ more productive in Java.

By "productive" I mean the time to find other people's libraries to do hard and complex tasks, use those libraries, compile and test until the program runs acceptably.

A prime reason is that the "self-checking" built into the Java language enables both tool support (i.e. accurate refactoring and accurate "IDE control-space") and very rapid development of a wide range of libraries.

Most other people agree with those sentiments; that's why Java is so dominant now, and Smalltalk and LISP are academic niche languages.

(Annoyingly, some youngsters want to throw the advantages away in the interests of "programming with fewer keystrokes").

Reply to
Tom Gardner

No.

Read the reference supplied; the relevant bits are only 9 pages - and are in clear and simple English.

It is the same principals and cost drivers at work. Your comment indicates you/Xilinx see the similarity.

... to you.

A key decision for /all/ businesses is where /not/ to compete.

Reply to
Tom Gardner

I added the command port to my test code. In a real spi device, there should only be one serial chain, instead of three in mine. But i don't need to follow the standard spec. However, resource ultizations should be similar. Using elements:

Max II: 67 / 240 ( 28 % ) Max 10: 154 / 8,064 ( 2 % )

I am using 60 cents of a $2 Max II, since i don't need anything else. Realistically, around 20 cents of a $10 Max 10.

----------------------------------------------------------------------

library ieee; use ieee.std_logic_1164.all; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity ram is port( P7: in std_logic; -- preserve upper 9 bits for next shift P6: in std_logic; -- preserve upper 10 bits for next shift P5: in std_logic; -- preserve upper 11 bits for next shift ACLK, clear, pass : in std_logic; -- Address serial clock ASI: in std_logic; -- Address serial in ASO: buffer std_logic; -- Address serial out A: buffer std_logic_vector(16 downto 0); -- Address register AA: in std_logic_vector(16 downto 0); -- Address parallel in DCLK: in std_logic; -- Data serial clock DSI: in std_logic; -- Data serial in DSO: buffer std_logic; -- Data serial out D: buffer std_logic_vector(7 downto 0); -- Data register DD: in std_logic_vector(7 downto 0); -- Data parallel in CCLK: in std_logic; -- Command serial clock CSI: in std_logic; -- Command serial in CSO: buffer std_logic; -- Command serial out C: buffer std_logic_vector(7 downto 0); -- Command register CC: in std_logic_vector(7 downto 0) -- Command parallel in ); end ram; architecture arch of ram is

begin process (ACLK, clear) begin if clear = '1' then A

Reply to
edward.ming.lee

So what you wrote is not correct?

This gets tiring. I don't know what "comment" of mine you mean and I

*don't* see the similarity. The interconnect in an FPGA is at least an order of magnitude more complex than the I/O routing in an MCU.

Ok, I'll spell it out. At the low end the multiple processors can implement separate tasks on separate processors. This works great simplifying the otherwise complex issues in emulating parallel processing on a sequential processor. Fine. A more complex set of tasks will typically require a more powerful processor although complexity is not synonymous with performance requirements. Once the XMOS device is fully utilized with one process per processor additional tasks require adding back in the complexity of emulating parallel processing on a single processor. So the primary advantage of the XMOS processor end once the tasking is complex enough, i.e. high end.

So clearly the XMOS is less useful at the high end and more useful at the low end. If they make some adjustments to the design/architecture to allow low *cost* units to be sold, that would only open more markets for them. One nice thing about the low end is that while you don't make tons of money on even a fairly large number of units sold, it pays to keep the doors open and the machinery running. Then they can pursue other products that have different economics and may be less stable financially, good one year and not so good the next.

So a processor company shouldn't try to compete in the processor business. Good thing ARM didn't try that approach. They definitely started at the small end and worked upward. I understand they are making significant inroads to servers these days.

I am feeling that this horse has been flogged quite enough. It's not going to get much deader and I don't think we are expressing much in the way of new thoughts.

--

Rick C
Reply to
rickman

...

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.

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.

Correct. An the important tests are the ones that test the functionality of the application, not trivial compile-time issues.

...

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.

No, but the serious errors aren't detectable by compilers, in my experience.

So does Forth.

...

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.

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.

We see both of those a lot. We use a 16-bit cell on those, and have

8-bit operators in addition.

Over 90% of the code we run on AVRs and ARMs is portable.

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, 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.

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. 
 Click to see the full signature
Reply to
Elizabeth D. Rather

No. Why would I care about the stage? In Forth, it does not incur a time delay to do it in the testing stage. Of course, in C that may be different, and you might ask why C compilers and linkers are so slow.

Which test patterns would that be? The test patterns I wrote for FLOOR5 are designed to test the values, not the stack depth; of course, the stack depth is tested in the course of testing the values. Or are you trying to move the goal posts towards correctness proofs by writing about "tools" instead of "compiler"?

Sounds like an excuse for C programmers who don't test at all.

That is contrary to my experience. E.g., in a Factor workshop the static type checker successfully prevented me from completing a task that would have been a breeze in Forth. It was a pretty small task, and I spent an hour or so fighting with the type checker before the time ran out. Expense: an extra hour, and a failed task. Productivity: zero.

When you don't have any code to start with, and want to focus on something else, insisting on perfect code for something you are not focusing on is an unwelcome distraction.

For what?

That's the theory, in practice it is treated as an alternative. That's what the gcc people apparently did, and that's what you also argued for above ("Why would someone bother writing test patterns ...").

There have been discussions about standardizing memory accesses to

8/16/32/64-bit values for quite some time, but they have not yet produced a final result. There also seems to be little urgency. It seems that Forth users who want to do such things are happy with the system-specific ways to deal with that.

Anyway, the usual way if you expect 32-bit values and a 16-bit system would be to use doubles. If that is time-critical code and you want to port it to a 32-bit system, you would rewrite it for the 32-bit system (maybe using conditional compilation).

Anyway, if we standardize one of the proposals for the memory access wordset, and these 32-bit values are in some network packet (in little-endian order) and are to be stored in another network packet (also in little-endian order), a piece of code involving your floor5 computation might look like this:

packet1 offset + l@ lle l>d dfloor5 lle packet2 offset + l!

[BTW, how do you deal with the little-endian issue in your portable C code?]

In the code above the 32-bit data is represented by a double on the stack (L>D just sign-extends if necesary). On a 32-bit machine a sufficiently sophisticated compiler (not that much sophistication needed with the DMAX-using version of DFLOOR5) could notice that the high cell of the whole computation is dead, and reduce the amount of actual computation to that of the single-cell case.

I don't expect that Forth compilers will ever do that, because doubles are rare, and the need to optimize them is even rarer.

Thought so. I.e., an unrealistic requirement that does not occur in practice is the basis of your claim of C superiority.

In practice, while I was using a system with 16-bit cells, I rarely used doubles (i.e., 32-bit values). These days I only use 64-bit and

32-bit systems, and again, I rarely use doubles, and very rarely in time-critical code. And when I use doubles, it is often because I need double-cell integers (independent of cell size), not because I need a particular bit width.

- 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 
 Click to see the full signature
Reply to
Anton Ertl

There is an other indication he has never run Forth. He aks for argument number checking while in even the most simple test argument count is implicitly tested.

It is easy to forget some tests .. in C. Testing in Forth means testing a small word with a few possibilities. Testing in c means testing a larger word with possibilities that are overlooked.

Example: I'm experimenting with a different looping. There are 10 words, one of which has more than one line. There are 17 tests. This level of testing is rare (if not unheart of) in C.

I use REGRESS similar to t{ . Anton Ertl is annoyed that I have made my own words, but the truth is it is so easy that only compatibility can be a reason not to roll your own. A few dozen lines at most.

One liners with one execution path are seldomly separately tested in C. It's too cumbersome.

Albert van der Horst

--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst

You have just ticked off Stephen. Steve or Steven is not my name.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

It is safe on Usenet - it is the best self-correcting medium :-)

I am quite happy to learn that modern mainstream Forth does not use blocks at all, and that the Forth used by the GA144 is a bit weird, old-fashioned, limited and niche compared to the Forth versions more commonly used in embedded programming.

(Have you looked at the GA website and read their stuff?)

Reply to
David Brown

He's obviously not talking about you, but about Steven Seagal, patron saint of hammy actors. You _really_ don't want to tick him off.

Reply to
Wasell

The testing thing in Forth is not insignificant. It is a great advantage to be able to test your code interactively (times when you can do that easily) and to test small functions (an advantage because other languages tend to have larger functions). But the examples provided are typically the lowest level routines where the base words are well defined and tested over much use. When the level of words increases they are more abstract. Still they work like the lower level words in many ways. But now the lower level words have only just been written and they may do what they were specified to do, but the process that developed the spec for the word can have flaws. Then these low level words are not doing what the high level word needs and expects. Now the testing is back to finding a bug at lower levels of code while testing the higher levels with all the issues that causes.

I'm not saying there isn't advantages in testing small Forth words, I'm just saying unit testing doesn't give a free pass at integration time which seems to be what some people suggest.

--

Rick C
Reply to
rickman

Sorry. I would have hoped for a smiley at the end of that post, Mr. Pelc. I think in one post I did refer to you as Mr. Pelc. First time I typed it, it came out Mr. Plec. Good thing I caught it. ;)

--

Rick C
Reply to
rickman

Lol. I can't be too mad at him for anything after he made "Under Siege".

--

Rick C
Reply to
rickman

It is odd that you rely so much on subjective/emotional words to describe what you like or don't like about a language.

--

Rick C
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.