Re: Speaking of Forth..



I would say you're clearly exaggerating about this one. There are still a lot of areas where assembler is the only "viable" option, especially in small microcontrollers and DSP-based projects.

FORTH has been indeed used in a variety of "embedded" applications in scientific areas, I'm not denying this. Anyone can go visit http://www.forth.com/ - which is nicely promoting the FORTH language.
As to LISP, unfortunately your example is the one that is off base in my opinion. You should have chosen your example more carefully to make a point. What you are describing is not what I call an embedded environment per se. You are talking about some kind of "scripting" ability built in a commercial software package. We may differ on what we both call "embedded". Clearly, in this kind of area, an interpreted, easy to learn and widely used language can prove very useful. Emacs itself, a very well known text editor package, is almost entirely based on a variant of LISP and can be enhanced this way. I wouldn't say it's the fastest editor around either. But arguably, it's one of the most feature-rich.

I haven't forgotten anything, I would even add that any programmer using C without knowing the underlying facts is a lame programmer.
That being said, data types is one of the things that define a "high-level language". The ability to use abstracted data types is very useful. I don't know how you can really define data types in FORTH. You can implicitly use them, yes, but not with a lot of abstraction.

Of course. Obviously. I'm just saying that the way of expressing data structures (especially when they become complex) is far from explicit using a language like FORTH, and still too "direct" to be called a high-level language.

I have learnt and used LISP in the past. I was probably going a bit overboard using the word "obscure". LISP can be used for pretty much anything, but it's essentially not suited for expressing inherently sequential tasks. It can be done, of course. But it can get very hard to read. In the same vein, PROLOG was advertised as the almighty programming tool in the 80's. I have learnt PROLOG, and as interesting as it was, I wouldn't use it in any embedded work. Just writing a purely sequential task in PROLOG is higly doable, but is exotic to read, to say the least. Of course, that may just be me.

You're right about that, nothing to add here.

I wasn't being rude to you or anyone else in this debate, so I'm not sure why you'd feel compelled to be rude to me.
I said I'm personally not "convinced of the practical use of interpreted languages in an embedded environment".
To begin with, I don't think it was that "strong" of an opinion, since I used the word "convinced". I could have gone like: "interpreted languages are crap", it seems like it would have made no difference to you. Oh well.
Anyway, saying what I said is a double-edged sword: for one, it means that I'm yet to be convinced, but that I'm open to if any solid argument and practical work can prove that to me. Secondly, it means that I'm still *personally* cautious about all the "interpreted languages hype" that's been going on for several years in most areas (I'm particularly thinking about Java, C#, and the like). I have good reasons to remain cautious and have arguments against it *especially* in the embedded world, I'm not going to write a 200-page book here.

Yes, I do know. Again, FORTH is an interesting concept, but there are, in my opinion (again, I only speak for myself), many drawbacks in the way it's executed, for instance we can raise issues about the code execution process in terms of security.

I'm not the one who raised the business considerations. I have to agree with you here. As long, of course, as the result meets a certain quality standard. Unfortunately, time-to-market is sometimes more important than performance. But that's an entirely different debate.

Yes, of course. Choices. Your example is interesting, by the way. You're right, but without being totally "stuck", you can still have your own views about things - provided they are based on something real and not imaginary, provided you can back them up with some *real* arguments, and not "emotional" ones. You can still have opinions, that doesn't necessarily do harm to your team - it can actually be a plus. Either way, all I would say is that if you *knew* that *you* wouldn't do a good job using some tools, you'd be entitled to offer alternatives. There is no absolute best, that's for sure. But there can still be choices that are better for *you* than others. That's also what makes you unique, don't you think? And if you are to dedicate your work force on some project, I still think you're entitled to have a say in the tools you're going to use. That doesn't mean you shouldn't be open to new stuff.

Well, I wasn't going into details. But, FORTH *is* stack-based, you can't claim otherwise, can you? And as long as there is use of a stack as the main storing space, that raises some specific issues. I'm not at all saying that it's an unusable approach.

Yes, you're right. "The right tool for the job" is not always as easy to define as you seem to say, though. Like you said before, there is no best. Besides (using your own arguments), you could always find some engineer who would maybe write a wonderful image processing package in FORTH.
Ultimately, you said it best: "So, C++ is the right choice for me and for that application class."
You can't claim there isn't a subjective part in the choice of tools you're willing to use, you admitted it yourself.

The key words are right here: *for you*.
I may have my own arguments against some tools you use, and likewise you maye have some against the tools I tend to prefer. That's what I call a debate.
No need to make people that don't agree with you 100% look like they are stupid and uneducated. ;)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

works?
...
I sincerely apologize if it came out that way. That was not the intention.
You have to admit that coming out and portraying Forth, the programmers that use it and the applications written in the language as amateur toys was just a little off-base given the wide range of commercial applications that the language has attracted. That sort of an assertion at the start of your email is what, in my mind, made everything else you said seem like strong opinion without a solid foundation.
From your post it is clear that you understand that there are no absolutes. And, yes, a lot of it is also subjective. A few points/corrections:
As you pointed out, I strayed off the path with the LISP discussion. I forgot that we were talking embedded. I don't know of any LISP-based embedded systems and I'm not sure it would be a sensible idea at all. I was just talking about the power of a language to modify the reasoning leading to problem resolution.

Well, you have to define the problem space first. If I am doing a project where the project timeline is much more important than absolute performance AND the processor is already fast enough that resorting to assembly coding would be a waste of time assembler is not the right choice. It might be (emphasis on "might") safe to say that a good deal of today's commercial embedded applications are written in C, with inline assebly thrown in for peformance-critical routines. I used to be really sensitive to code bloat. But, look around you, unless you are using the little $0.99 PIC's and similar low-end processors the power, speed and memory capacity of todays embedded processors is mind-boggling compared to just a few years ago. Look at what's been happening to the '8051 family, for example. From 12 clock per instruction cycle to 1~4 in modern clones. Some chips have 64K of RAM and FLASH ... all for $10 in production quantities. So, as a business owner, what would you have your programmers do? Get the project done quickly in C (or Forth, or Basic) and get the product to market quickly or have them diddle with assembly and take twice as long?
That's why I said that assembler should be the last resort. In non-consumer (read: cost-sensitive) applications, I rather replace the microcontroller with a more capable version, spend another $5, $10 or whatever is reasonable and enable the programmers to go as fast as possible with a language above assembler. That's just the business equation intersecting with engineering. Real life.

You simply define a family of words that know how to treat whatever data type you need to operate with. After that it's a piece of cake.

Yeah, it is. What I was thinking about though are applications (and there are a lot of them) where the performance of even the cheapest of todays embedded processors is so far beyond what you need that you might as well use the fastest tool to get the job done, since no perceivable performance penalty will be evident. Does a digital sprinkler controller really need to be coded in assembler? Proabably not. Or how about a little processor that runs a machine's control panel (a bunch of buttons and knobs), probably don't need assembler in this case either. Now, if you are running servo motors for an high-speed industrial machine of some sort, well, that's different. You are almost guaranteed that you will have to use some assembler, if not having to write the entire thing in assembler. Years ago I did a design using a PIC16C56 that needed to squeeze the last bit of performance out of the chip. I didn't have clock cycles to spare. Of course, assembler was the only way to achieve this.

No, of course. But you don't use the stack to store your arrays or structures, it's simply a working space, if you will.

I'm sure that could be the case. But not on my dime, that's for sure! :-)

You bet.
BTW, I'm working on a project as we speak where I made the mistake of using the wrong tool. I wrote this whole application in assembler (Cygnal 8051) and I now wish I had used Forth or C. The application ended-up growing to the point where I know it will be a pain to support and (more importantly) get others to work on it in the future. So ... I'll probably either have to re-write it myself using another language or pay somebody to do so at a later time. Oh well.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Yup.....
Stack based assembler approach.....
Push Operand A Push Operand B Add Pop Operand C
Forth style..... A B + !C (ISTR)
Is there some difference here?
Like all assemblers, if you make an elementary error in register handling, such as popping a return address from the return stack your program fails in a way that is only possible in an assembler.
(Excepting array bound errors in, C, for example)
The seminal ideas in Forth were published in a two-stack computer, the English Electric KDF-9 long before Forth came along.
wrote

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

How and where have you looked?
I doubt any of my customers at IBM, DEC, G.E., Los Alamos Labs, Sandia Labs, Bell and Lucent Labs, JPL, MIT, NASA, Scripts Institute, Woods Hole, Cummins and all three big automotives, etc. etc. etc. would appreciate being told that they either weren't serious or professional.
Also, blueeyedpop, with whom you are taking exception, has won an Emmy from the Academy Awards for technical excellence on his computer controlled lenses. Or would you maintain Steven Spielberg isn't serious or professional when he specifies blueeyedpop's lenses for some of his movies?

Are you repeating something you've never tried yourself? Then, how many Forth routines have you seriously tried to read? Or is this an admission you tried to read some, and in the words of the post your reply to couldn't, "be bothered to get trained properly."
This "Forth is practically unreadable" is an old bromide, without great validity. Yes, Forth is powerful enough to write almost unreadable code. It is also powerful enough to write a small interface layer by an experienced programmer, and then almost natural language code in the hands of beginners. The notion _any_ routine in Forth is practically _unreadable_, is uninformed and silly.

So, wouldn't it be better to ask questions about what you don't know? than make pronouncements which might mislead?
As far as stack resources, can you name a high level language with procedure calls which isn't stack based? It sure isn't C. The stack (not to mention heap) requirement of C far can exceed what is required by Forth.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Lots (of) Infernal Stupid Parentheses

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Well, let's at least admit it: the main reason why LISP was even created at first, was the extreme simplicity of the needed underlying interpreter, due to the extreme simplicity of the syntax (really, how much rawer can you get...)
Then speaking of RPN, I have a hard time seeing how "A B +" can be more intuitive than "A+B". It's much simpler to write a RPN expression evaluator though, and that's probably what motivated it in the first place.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I'll take your word for that. I do have somewhere in my paper archives a LISP interpreter written in LISP; probably only half a page of code.

PN evaluation.....
1. PUSH each operand onto operand stack as it is encountered (same process as RPN) 2. IF Operator is higher precedence than previous stacked operators, then PUSH onto operator stack... ELSE POP and execute each operator that is of higher or equal precedence to latest operator then PUSH latest operator onto operator stack.
Do not stack brackets, but make them increase (LH) or decrease (RH) the precedence of all subsequently stacked operators by HIGHEST_PRECEDENCE + 1.
Unaries are dealt with by PHP (Pretty High Precedence!)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
A rather over-long reply, most of which went unread because it went off the bottom of the page (the tribulations of bottom posting!)
ITYM, _TRIVIAL_ microcontroller systems. There are many microcontrollers on the market, in particular the ARM derivations used in GSM phones which sport several megabytes of on-board program flash and whose program code is produced and maintained by teams of 100 softies.
For _VERY_ obvious reasons, FORTH is not used in these apart from some trivial booting routines produced by electronic engineers who are otherwise untrained as softies.
In my career, I have seen many instances when well-paid electronic engineers became grossly-overpaid junior programmers. The code they produced had the same quality as any other code produced by untrained junior programmers. PE and CEng are no guarantee of coding capability!
That an application is used in space systems is no guarantee that the authors of the program were professionally competent in the software that they themselves wrote to accompany their own hardware creations.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
</END FLAME>
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The obvious reasons?:
1) It would be difficult to hire 100 forth programmers, as they are harder to find (which, in fact, is a common reason why a language like FORTH doesn't get used - need for experienced practitioners)
2) You wouldn't need to employ 100 people if it was done in FORTH. Nor would it be a 9 month (or whatever) project.

Neither is a CS degree.

It would be equally misguided to put "softies" on the project who were not versed in hardware specifications, idiosyncracies, failure modes, basic physics, etc...
One of the beauties of FORTH is you can use it to create a problem-domain specific language and remove an "applications programmer" from even the knowledge or impression they are using FORTH. The same caliber experts who would create the unbreakable C-libraries or C++ classes would create the domain-language in FORTH. With far fewer people and less time, from most stories I've heard. I've *never* heard a story told where an equivalent application was build in FORTH, assembler, C, C++, Visual Basic that required less time and personnel by not using FORTH.
Rufus V. Smith Home Page: http://members.aol.com/rufusvs
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Is there something in the psychology of FORTH programmers that is not in the psychology of other softies that enables them to deal with many more function points on a daily basis? Hardly.
How does writing in FORTH bring about a more rapid analysis of the problem domain before committing to code? The answer is that it does not. FORTH is a hacking language where trivial applications may be coded without a great deal of thought. For _EXTREMELY_ complex applications the bulk of the effort is in the design, and the ultimate implementation language does not reduce the design effort required.

Agreed absolutely. I'd rather hire a graduate in a _REAL_ engineering discipline to do software; someone with a practical bent. CS graduates are just so much arrogant rubbish.
Rest snipped as too long and went off the bottom of the page.....
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Lot's of do's and don't there, your sudden highness. Sorry, I don't respect the concept of someone-out-of-the-blue telling me what to do, and what not to do. I'll return the favor with a bit of advice. Don't be so silly.
As far as Forth in business, perhaps you think all those Sun Sparc stations shouldn't have a place in business, because they rely on Open Boot, which is, oh yes, a derivative of Forth, without which they couldn't boot up.
And then we should require everyone to abandon PostScript, which made Adobe one of the highest-grossing-per-employee software companies in the world.
And then we'd have to tell FEDEX to stop using their terminals their drivers rely on. You know, the ones that positively, absolutely help FEDEX get it there overnight.
Just to mention a brief few...
You are certainly not the boss of me, despite your imperial bravado. For my part, I am a self made businessman, with 20 years experience as President/CEO, with a company which has averaged more than a million per annum for more than a decade. I have to wonder if you are the boss of anyone, and how you can imagine you can speak for the business world. If you want to be credible, tell us what position you have in business, that you imagine you can tell others not to "bring Forth into the business world, we don't have time", particularly since 1) it is already there, 2) and has been the past 20+ years, and 3) saving business time and money is one of the key reasons many of them consider the use of it "a trade secret".
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
etc, etc.
Grow up, OM.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
How does an architecture that does not have any stack processing at all, be "as close as you can come to a FORTH chip"?
Sure, there are published ways to implement stacks in software, but these typically take a sequence of 6 to 8 instructions to implement, AN INTERPRETATION OF STACK PROCESSING. and interpretation is where I came in.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
It didn't have a stack archetecture exactly, it had 16, 16 bit registers that could be used to point anywhere in the memory. So, on register is the stack pointer, one could be the return stack pointer, one could be the instruction pointer.
In fact, the COSMAC had no gosub command. You were supposed to use threaded code like FORTH. Any of those 16 registers could be the program counter. There was a command that made a specific register the current program counter. If you wnated to do a subroutine you load a register with the address and then made that register the current PC and off you went. Just like FORTH.
The later model of the COSMAC - the 1805 - was designed for FORTH, with a stack pointer, commands like swap and drop ( I think... it's been a while) and other enhancements.
I miss my COSMAC. If I had an EPROM programmer I'd run over to HSC and pick up a few to play with.
--
chris in napa
"Airy R Bean" <SPAM@trap> wrote in message
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
A.) A stack is a software structure. As long as you have RAM and a pointer to RAM, you can make a stack.
B.) FORTH IS an interpreteted language. The COSMAC's wierdness makes implementing a FORTH interpreter rather easy. The later model 1805 used FORTH primitives in it's machine code, an acknowledgement , I guess, of how the COSMAC's were being used.
C.) In the data sheet form HARRIS, they describe a GOSUB/RETURN scheme that is exactly the same as the return stack scheme in FORTH. One register points to RAM - this is the return pointer. One register points to a "CALL" routine. One register points to an "EXIT" routine. One register is designated the program counter.
To call a routine, you pointed the P nibble (the register that controls which of the 16 registers is the Program Counter) to the "CALL" register. "CALL" saved the Program Counter on the return stack, loaded your subroutine in the Program Counter and ended by pointing to the Program counter. The end of your subroutine pointed to the "EXIT" register. "EXIT" undoes "CALL".
and...
D.) Dude! You're putting WAY too much energy into this, I'm missing the point.
FORTH was made to control machines. I wouldn't write a spreadsheet in FORTH, but if I want to control a machine, FORTH makes fast, compact code, AND I can write the program directly to the machine. None of this write it on a PC, burn it in the chip, debug it and start again, stuff. I think this is FORTH's biggest advantage.
FORTH is no more or less incomprehensible than C. : ; is no more difficult than { }. With FORTH, the shorthand was done to save space in the kernal. I don't know what C's excuse is. If you want readability, stick with PASCAL.
FINALLY....
If you don't like it, don't use it. Stop putting people down for not being you!
--
chris in napa
"Airy R Bean" <SPAM@trap> wrote in message
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Whoot! There it is

registers
You
the
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Actually, back in the 70's, I used to write machne language code to play single note music on my 6800 machine. Memory was very tight back then. 1K (yes 1024 bytes!) of RAM was a deluxe machine and you had to be very economical in what you wrote. Plus who wanted to hex keypad bang in all that much code?
My father, on the other hand, used an 1802 processor and wote identical routines to play and share the same music. His total packages were always within 1% of the number of byte to write the code as my 6800 (known to be very efficient, well structured code and well structured architecture type of CPU). The 1802 packages where just as fast and included his JSR and RTS routines to achieve the packages.
Despite the preferred style of CPU the 1802 matched the 1MHz 6800 on every basis.

controls
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Not really true. It could do the JSR/RTS routines just as fast as a processor with those built in. You were just coding at a lower level to start with. Every instruction took two cycles. Faster than most CPUs of that day. The Intel CPU's were so slow by comparison taking many cycles to do everything. I dropped out when they became popular as I was a structured machine code/assembler type without the tolerence for the muddle head/instruction set count contest.

play
1K
always
be
type
RTS
every
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
No..each semi-micro instruction took two cycles. The JSR was about hmmmmmmm.....let's see
Label: resetPC switch PC back to normal (does JSR jump) Label: JSR load low jmp addie (with increment) put low normal PC load high byte Jmp addie (with increment) put high normal PC get high byte old PC stuff into stack (self decrementing?) get low byte old PC stuff into stack jmp back to resetPC
Remembering way back now...LOL We have a total of 10 bytes of code at 2 cycles each = 20 cycles (1 machine cycle = 1 clock cycle unlike Itell and other goofball concepts) I believe the 6800 was 9 cycles to do the same and 2 or 3 bytes of inline code. The 1802 took 3 lines of code for a 64K relative or absolute JSR. Actually you can design your own style of address independant code or any style you liked (or both)
The inlne call was this change PC to JSR code addie followed by the address

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.