The current release has over 300 downloads, and the previous release v4.6 had over 300 downloads.
You and anyone else may interpret the data differently; for my purposes we will assume there are at minimum 300 engineers that may at some point wish to look at the references. This is like any other very large project, it is under estimated by two orders of magnitude.
That being said, it is correct to say it is underfunded.
Just a bit curious on how you got the Propeller to do 64 bit encoded assembler and how I am ever going to get up to speed on that. After all, the Propeller is a 32bit device. Please point the way to this bit of new news.
Google 64 bit encoding, and look at radix 64. This has nothing to do with how the part represents values, it is about how many characters are used to represent values. This is an old technique used to minimize the number of bytes needed for storage or something.That is, it you use ascii characters to represent binary digits, each bit needs one byte to represent it. If we use HEX, we can use 0-9 and A-F. If we use base 64, we can use 0-9, A-Z, and a-z. Peter entered a bug about this, complaining that the NUMBER function accepted characters past 'F'. In fact this is by design to accommodate that maximum number base possible, it is not a bug at all.
This is another thing that has to do with packing the assembler optimized code. It is very easy but not until we get to that point. Save this for February.
OK, I started working a better way to organizze the docs, but got stuck.
The concept is that the download is self contained, but auxiliary resources are on the google code site.
Since the Propforth.HTM file is alway locarted in the same location in the download archive, I asked Sal to provide local relative links from the entries in section 9 to the txt and .f source code files that define each forth word. I won't know if he can do this till he gets back from his travels.
In the meantime, I tried to put a copy of Propforth HTM on th wiki, so we could access it from a browser without having it on the local hard disk. This is necessary for obvious reasons.
The goal is to have the propforth htm file available as a webpage on the internet, and be able to click on each word (in section 9), to display its source code.
This is proving to be a big effort to re-edit the text. I haven't even gotten it to display correctly, let alone add all the anchors so we can click through links to the source.
And soo.....
Your '64bit optimized assembler code' is not really 64bit assembler code. It seems to be conventional 32bit Parallax Propeller assembler code that has used some Google 64bit algorithm to tightly pack it in the dictionary space.
And I should wait until February for an explanation. ... or something.
I looked at the .htm entries for serial and _serial. Can you assure me that they were designed in a fashion that the rx and the tx pin can be the same one?
I strongly suspect that this is NOT the case. That the serial configuration will crash. And that will be the end of my chopstick printer project on Forth.
Meanwhile I will first try to get a serial loopback working in PropForth at 9600 8N1 and then if I can make that work, I will proceed with my own testing for a possible crash.
If I haven't mentioned it already. the replacement Inkjet cartridge has been ordered. And hopefully it will arrive in time to have an actual printed chopstick.
" That being said, it is correct to say it is underfunded."...Prof Braino
Underfunded? Does that mean you are actually being paid by someone for your efforts? I am intrigued.
And soo.....
Your '64bit optimized assembler code' is not really 64bit assembler code. It seems to be conventional 32bit Parallax Propeller assembler code that has used some Google 64bit algorithm to tightly pack it in the dictionary space.
And I should wait until February for an explanation. ... or something.
That's interesting.
i seem to be having trouble with english.
did you do the google thing? it really explains it well, or at least better than me.
also, i meant it will not be until february until you can understand what the more advanced stuff is about.
if you don't read the material, it will take a little longer
I looked at the .htm entries for serial and _serial. Can you assure me that they were designed in a fashion that the rx and the tx pin can be the same one?
no. this is incorrect.
Underfunded? Does that mean you are actually being paid by someone for your efforts? I am intrigued.
Have been working through the examples, but haven't had the time to do these in actual PF. Will continue to do so. I seemed to have gotten EMIT incorrectly and it will work fine with binary.
"No, this is incorrect."
Does that mean ......
A. YES, I can use the same pin for RX and TX in the 'serial' word
B. NO, I must use separate pins for RX and TX in the 'serial' word
If YES, I then need to check the RX buffer for a prompt before a TX is initiated.
And I need to clear the RX buffer after each check. I am beginning to see there might be a way as long as I clear the RX buffer at certain times. The prompt is a > and with the shared TX/RX pin I may fill the buffer with CR or CR/LF that will have to be dumped or ignored.
I might be able to do the following...
1. clear the RX buffer
2. send a CR/LF
3. check the RX buffer for 'CR/LF >' sequence and interpret that as a ready for reception condition.
4. transmit a string of data
5. go back to #1 above.
When I look into the source code for 'serial' and '_serial', such details appear to be coded on assembly language. Rather than try to explain the hardware details again, I am providing a link to the document.
I did locate hexidecimal 8 bit references to an RX buffer and TX buffer. I guess these must be offsets from some starting point but I am a bit uncertain where that would be. I am guessing that PAR might have a possible starting point, but this is a rather wild guess. I'll keep trying.
If I can verify the RX buffer, I can use FILL to make it all zeros.
A bit more progress... but I am not writing any code as of yet.
I re-read Chapter 6 of the PropForth.htm and located the io word. It seems that is equivalent to sc par COG@ . when the console is active in any given cog. So this I am presuming is the origin from which the RX buffer and TX buffer are offset as mentioned in serial and _serial.
In other words, I have found a working hypothesis for clearing the RXbuffer. And so, tomorrow I hope to sit down again and re-read the Chapter 6, all the serial and _serial information and the 3.2 serial loopback with some testing of RX pin equal to TX pin configuration. I have read the SERIAL wiki as well.
If I can at least get the second Serial port up and running, I may work out the rest of the details.
I am hoping the ink cartridge will arrive tomorrow and I still have to bench test the two 5 wire stepper motors through a rotation sequence.
~~~~~~~~~~~~~~~~~~~~~~~~~
Arg.... I hit another snag in one pin bi-directional. The pin i/o will have to be toggle between input and output. Lucky that I thought of this.
I think that will nicely complete the sequence I mentioned of clearning the RX buffer
1. Set the Serial shared RX/TX pin to pinout
2. Clear RX buffer by filling with zeros
3. Send a cr or a cr/lf (as required)
4 Set pin to pinin
5. verify that a cr > or cr/lf > have arrived
6. Set pin to pinout and wait
7. Send whatever coded string is requried to print, such as <STX> some text <ETX>
8. Wait for print head to complete its output
9. Go back to number 1
Either that will work or I am just chasing rainbows. Yes there is an extra set pin to pinout in there. I am thinking about having two entry points to this loop. One is for me to start the process, which is at #1 and a second at #7 that is triggered by data arriving in the TX buffer. I am not sure if this is silly or wise at this point.
Regardless of pinin or pinout state, the single pin will be an active loop back between the two buffers at all times.
Success may depend on how fast the pin can be switched between pinout and pinin and back again as the Serial Inkjet Printer Board may not have any delay in response with a prompt. I have to check that code for available delay.... and maybe add a longer delay in the SX28 code.
Have been working through the examples, but haven't had the time to do these in actual PF.
thus your confusion.
"No, this is incorrect."
Does that mean ......
It means "it works the ways it works, you start by figuring that out, and decide how to change it to do what you want". Which is not as un-helpful as it sounds.
The provided serial examples are designed to talk on one pin and listen on another, and to have the mechanism running continuously. What you appear to need is TWO SEPARATE words, one to talk, and the other to listen. Instead of continuous, you want them bounded by bytes or timing. And your application will alternate calling talk and listen. I haven't done this yet, but you should be able to take the example, and use it as a starting point for your talk and listen words.
It means "it works the ways it works, you start by figuring that out, and decide how to change it to do what you want". Which is not as un-helpful as it sounds.
The provided serial examples are designed to talk on one pin and listen on another, and to have the mechanism running continuously. What you appear to need is TWO SEPARATE words, one to talk, and the other to listen. Instead of continuous, you want them bounded by bytes or timing. And your application will alternate calling talk and listen. I haven't done this yet, but you should be able to take the example, and use it as a starting point for your talk and listen words.
Hi,
I do acknowledge that I seem too needy from your point of view. Hopefully we can change that and go foward.
On the other hand, it just could be more un-helpful that you can see. I just wanted to know if the serial and _serial support a half-duplex configuration. Without support in the assembler code, it just may be a complete waste of time.
A word search of the PropForth.htm only has full duplex mentioned in discussions of the MCS and nothing in the Serial feature. There is no mention in the text of half-duplex anywhere.
There are occasions that everything is NOT in the .zip file source code and documents. I seem to have come across one of those. Try your word search of the PropForth documents for full-duplex and half-duplex or full duplex or half duplex or duplex.
And this appears to be one of those situations where something was not included.
Since Sal Sanci is only available to you, I turned to you due to the time element in this little contest, but I guess the only real channel of communication with Sal Sanci is to post a Issue report in the Google PropForth.
It is very likely that this cannot be resolved in the time frame of the contest. I am okay with that. I have learned quite a bit. The PropForth serial function is quite interesting, and it also has some very real limitations.
Okay.....
Let me clarify exactly what 'works the ways (sic) it works" from my view point.
1. I need half-duplex RS232 and PropForth seems to provide only full-duplex RS232.
2. I cannot locate anything in the documentation that claims the Serial code is able to reconfigure from full-duplex to half-duplex. It seems that is buried in Assembler code. I cannot even confirm that the serial driver is full-duplex, but it seems to behave like full-duplex and the MCS is claimed to be full-duplex.
3. I simply have two choices -
A. Abandon PropForth as it doesn't provide adequate serial port functionality to use with some Parallax products (the Serial Inkjet Printer Board is a Parallax product). At this time, I am not up to writing a PASM full serial suite for PropForth.
Or
B. Try to manipulate the serial port in ways that were never considered by the developer to make half-duplex bi-directional RS232 serial work with the full-duplex code provided in this instance.
In sum, it seems that 'it works the ways it works' is your way of saying.... "No reply, read what's available, and sort it out on your own".
WILL DO, OVER AND OUT.
See, I do understand. I won't bother you with more PropForth questions as I seem to have gotten ahead of you.
But I DO advise you and Sal Sanci to consider documenting for V5.03 that your serial support is only for one type of RS232 and that it is full-duplex 8N1 at a variety of baud rates that are unspecified. The user will have too write a replacement driver for 'serial' and '_serial' if they need other choices or develop a hack on their own.
On the other hand, ever since the BS2, Parallax has tried to provide complete RS232 support in the full suite of configurations. So that makes PropForth as it exists in V5.03 a less useful serial support device.
Everybody starts with 8N1 when they provide serial, as it is the easiest and most compact driver to provide. But at times there are requirements for parity, hardware handshaking, and software handshaking. I do understand that this is minimalist Forth, and 'more is less' and 'less is more' and so on.
But functions are features are utility. More serial options, more people will use PropForth.
Tachyon Forth provides half-duplex, so I may have to switch over to it for this project.
Person writing codes for Propeller-chip is few.
And Forther for Propeller is very few.
I had wrote junk-codes from v2.7.
But almost nothing replys.
But I'm fine, because I like to write forth-codes.
When PropForth doesn't provide functions you desire, I think you should write your desired codes.
If you don't know how to write codes, you should write questions in this thread.
I don't have known RS232 well and written its codes. I can think its code together.
Selection Tachyon Forth might be successfull.
But when Tachyon Forth doesn't provide functions you desire, you switch to other Forth?
Hello Caskaz,
Thanks for your reply.
At this point I am not certain that I could write a good serial support for PropForth. I just don't have the skill and experience. But I am enjoying PropForth and may be able to do so one day.
RS232 serial ports are very handy with the Propeller for working with all sorts of old and odd equipment. But there are lots of choices for configuration. As PropForth is now, it only provides 8bit, no parity and 1 stop bit at various baud rates (maybe any baud rate in a range). And it is full duplex.
It will take time for me to write something and we have a little contest that is supposed to have something finished by Nov 25th, (at least I think that is the deadline). I am probably not going to make it, but it has been very useful to learn about the limits of the serial connections.
I will keep studying PropForth and try to improve.
The main point is that the user needs to know when something isn't provided just as much as what is provided. So far several words that are very useful in other Forth are not available, also there is not clear support for creating arrays, and now I discovered that only 8N1 full-duplex, no hardware handshakes, no software handshakes are supported.
These thing are all features that users might want and will look elsewhere if PropForth doesn't have them as it might be faster to learn another version of Forth of the Propeller. I'd like to see PropForth succeed in becoming one of the best.
I don't really want to change to Tachyon, but if I cannot connect with the board I am using, what choice do I have? Spend weeks studying PASM and writing a new serial port via reverse engineeirng? Or just give up Forth?
The software must serve all sorts of hardware to be successful. The easier it is to learn, the more popular it is as well.
I just wanted to know if the serial and _serial support a half-duplex configuration. Without support in the assembler code, it just may be a complete waste of time.
Each HALF of the communication is HALF duplex. One Talks, the other Listens. Your mission, should you decide to accept it, is to make a separate word that talk on the transmit pin, and a separate word the listens on the RX pin. However, if you do not accept this mission, your project will delf destruct in 5 seconds. Good Luck, Mr Phelps.
Your assessment of the need for assembler support is incorrect. As you can see from the source code and the example(s) (you really, REALLY got to read the materials and do the exercises to learn the stuff. A teacher told me this. Ask a teacher if this is true.) the serial is implemented in regular, plain old high level forth. This can do 9600 all day long and not break a sweat. We only need the optimized serial when we need to faster than 57600. At that point we can go 3 million baud as Peter has shown, but Sal de-rated it since he noticed a stability issue in one test over very long distances (but he might have tripped over the wire or such) and we do plan to do the really high throughput over MCS and Ethernet.
I don't want to come off as snippy or condescending, but I have mentioned this reading the materials on more than one occasion. Reading Starting Forth is great to learn about Forth in GENERAL, but is pretty useless for using any forth in particular, except the orignal polyFORTH (from Forth Inc) for which it was written, and possibly Dave's pfth, although I pretty confident there will be significant difference between Brodie's examples and the standard (described 20 years later) at some point in the book.
To learn propforth, you have to concentrate on the function you are trying to make function. Do not worry about all the dictionary structure, threading model, assembler, optimization etc until you get there. Look up the word in propforth.htm, look up the word in the source code, try the examples, and run the tutorial. If you don't do all these steps, you have a decreased likelihood of success.
There rest of your post is not really actionable until you have done the reading and exercises. If you wish to abandon propforth, so be it. Perhaps propforth is not a suitable tool for your purposes.
There is no mention in the text of half-duplex anywhere....everything is NOT in the .zip file source code and documents. ...And this appears to be one of those situations where something was not included.
This is correct. Stuff that was determine to be "not needed" receive no effort. Think about it. How big would the kerenl be if we tried to implement every possible permutation that no-one will ever use? We would have Windows. Sorry, that won't fit is 32k. Maybe 640k?
Since Sal Sanci is only available to you, I turned to you due to the time element in this little contest, but I guess the only real channel of communication with Sal Sanci is to post a Issue report in the Google PropForth.
WILL DO, OVER AND OUT.
This is unfortunate, but you misunderstand the relationship.
Notice that you are the only one who has mentioned half duplex support and documentation. Who should do this work?
We get to use Sal's tool, because he's nice and shares it with us at his pleasure, with no obligation. Sal will NOT do your homework for you, no one may make any demand of him for any reason whatsoever. You ask nicely or are ignored. This is why he does not respond to the forums. People can get exited and neglect decorum. Sal does significant work at my request because I ALWAYS take great effort to only ask for things that greatly overlap his work in progress. Requests further from this model are less likely to be fulfilled quickly.
Give my regards to Sal. You seem to blockade real discussion with claims that he is the one that knows what is best for all.
I have no intention of being someone's Forth groupie with Sal as my 'master' and you as the 'keeper of the flame'. I may continue to use PropForth, but my expectations have been substantially lowered.
The thing is that you keep throwing back inquiries of what is and what exists by saying that I am asking for something that I should create or document or waste time searching for in a fashion that is unclear.
The net result is the very real experience that PropForth is trying to be something it isn''t.
I have never expected Sal to 'do my homework for me'. And that is you speaking, not Sal. There are real and obvious absurdities in the liberties you take in speaking for others. If and when Sal has something to say to me, you can give him my email address.
I don't have halfduplex-hardware.
Your device's signal-line is only one?
Are there anymore line?
Please be clear hardware-spec(speed,stop-bit,parity,etc).
Wow. Little confused by this over here, the conversation keeps going further in the wrong direction. I've been trying to keep responding to the threads while doing other responsibilities, it looks like the communication has fallen apart.
So, you don't want to examine the code, and you don't want to work through the examples? I'm not sure what else to recommend. As far as I know, that's where we have to start. If this is unsuitable, I'm limited in the help I can provide. I can try to answer questions as best I can, but I just do docs and testing, so I can only go so far with the time I have available.
I'm not sure where the 'master' and 'trying to be something it isn't' is about. Propforth is just a tool. There's code that functions correctly, and examples that show the correct operation of each function. That is the resource available to us. Each function only does what it is intended to do; if we wish to change that, we take this task upon ourselves. We can change anything we want to extend the tool in any direction we choose. The kernel is just a starting point.
Don't give up on Forth, there are others options. The competition dead line did not give much time to get a project up and running. .I started to port and upgrade the old "Dr Elisa " the AI game from years ago. It is to run off a SDcard but its not going to get finished for this comp.
I believe there will be another comp next month. Thanks to Peter Rick and Co.
I know what you mean about Propforth, but Sal choose not to participate in the forum, that's his choice. One of the good things to come out of the gcc project is that we will have an ANS Forth running on the Prop, thanks to Dave Hein. I don;t think it will be the last. .
It's an ANS Forth and it looks like it's really fast. I have had a play with the C version. It is so easy to install.. It runs in a shell so you can install any flavour you like ansi.fth, ansi3.fth of if you must, you can even roll your own (DONT TRY IT) . You don't have to know anything about C. There are also words in the starting.fth file which you can install which allows you to do the exercises in the Starting Forth book.
You can also look at this tutorial. 27 pages mostly ANS standard.but is written for beginners to pforth( portable forth)
Once you are comfortable in forth its not too difficult to move to Tachyon of other specialist versions. Tachyon looks like it's tailor made for you project.
Send me some chop sticks when your project up and running, I used them for eating amongst other things for two years or more when we where in Pula Penang.
Keep pluging away Propforth Tachyon, mv4th,JDforth, or ANS forth, which ever you are comfortable with. The tutoral above is worth a look.
I don't have halfduplex-hardware.
Your device's signal-line is only one?
Are there anymore line?
Please be clear hardware-spec(speed,stop-bit,parity,etc).
Hi Caskaz,
It is nice to hear from you.
Yes I have only one wire, it is bi-directional. I attached a file with complete documentation of the board in the above threads. But it might just be simpler to explain. The board is a Parallax product that was made for Hewlett-Packard and they used these to support there industrial side of Inkjet Printers. It is used to apply expiry date stamps and batch codes in automated packaging. So I am not using something that is not in normal commercial use.
Communications require half-duplex 9600 8N1. PropForth may be able to handle this on two wires quite easily, but one-wire is something a bit more difficult.
The board could be said that it acts as a slave.
There is a bit of handshaking. If I send a CR, the board sends back a > to show that I have an active line and that it recognizes the serial baud rate. I can do this without using PropForth, so I know the board works.
After that I can send a <STX> up to 64 ASCII characters <ETX> and the printer head will print all of them.
And then the board sends another > to me to tell me it is ready again.
I have studied the Tutorial 3.2 for Serial Loopback. It is quite complex as it used 5 cogs to do something that I had thought should require only 1 cog. I still don't understand all the code in the 'term' word and there is no explanation of that words. In fact, it is a bit unclear as to why 2 and 0 are put on the stack before it. I guess these are cogs tied to an RX and a TX.
There is also a word to set the serial flags, but how many flags there are and what setting them does is not explained.
There are also words for making io connections and links internally, but not much is said about any of these. So I am pretty much on my own to dig all this out.
The whole idea of these forums is share knowledge. But like you, I am forced to just dig up answers on my own. I feel rather buried in code at this point without any overview from people that might be able to provide overview.
So I try to create my own overview and summarize what I've discovered. Some people say it is very helpful, others say I am wasting time asking questions.
Wow. Little confused by this over here, the conversation keeps going further in the wrong direction. I've been trying to keep responding to the threads while doing other responsibilities, it looks like the communication has fallen apart.
So, you don't want to examine the code, and you don't want to work through the examples? I'm not sure what else to recommend. As far as I know, that's where we have to start. If this is unsuitable, I'm limited in the help I can provide. I can try to answer questions as best I can, but I just do docs and testing, so I can only go so far with the time I have available.
I'm not sure where the 'master' and 'trying to be something it isn't' is about. Propforth is just a tool. There's code that functions correctly, and examples that show the correct operation of each function. That is the resource available to us. Each function only does what it is intended to do; if we wish to change that, we take this task upon ourselves. We can change anything we want to extend the tool in any direction we choose. The kernel is just a starting point.
I do now understand that your time is limited and the docs are rather limited.
The other stuff is merely a product of frustration as it had seemed that the documents were further along than they are, and several other misperceptions.
I can adjust.
I have worked through the Serial Loopback Tutorial and it works. But there really is no explanation of why. It is very WYSIWYG. It works, but I don't see how to apply any of what it demonstrates in any useful way. Five cogs for a loop-back is a lot of real estate for one function.
I can go from word to word digging out meaning on my own, but I thought there was some mutual benefit to be gained in collaboration. I submitted a rather long list of writing tasks that I had accumulated.
Don't give up on Forth, there are others options. The competition dead line did not give much time to get a project up and running. .I started to port and upgrade the old "Dr Elisa " the AI game from years ago. It is to run off a SDcard but its not going to get finished for this comp.
I believe there will be another comp next month. Thanks to Peter Rick and Co.
I know what you mean about Propforth, but Sal choose not to participate in the forum, that's his choice. One of the good things to come out of the gcc project is that we will have an ANS Forth running on the Prop, thanks to Dave Hein. I don;t think it will be the last. .
It's an ANS Forth and it looks like it's really fast. I have had a play with the C version. It is so easy to install.. It runs in a shell so you can install any flavour you like ansi.fth, ansi3.fth of if you must, you can even roll your own (DONT TRY IT) . You don't have to know anything about C. There are also words in the starting.fth file which you can install which allows you to do the exercises in the “Starting Forth book.”
You can also look at this tutorial. 27 pages mostly ANS standard.but is written for beginners to pforth( portable forth)
Once you are comfortable in forth its not too difficult to move to Tachyon of other specialist versions. Tachyon looks like it's tailor made for you project.
Send me some chop sticks when your project up and running, I used them for eating amongst other things for two years or more when we where in Pula Penang.
Keep pluging away Propforth Tachyon, mv4th,JDforth, or ANS forth, which ever you are comfortable with. The tutoral above is worth a look.
Ron
Thanks Ron,
I actually do like Forth and think it can be a lot of fun. For the past 18 years I have almost never seen a fork, knife or spoon. Chopsticks for everything here.
In fact, I think we all really like Forth. It is just that it seems that getting it into a presentable fashion for use on the Propeller will take some effort. As it is, mostly people that can handle coding quite a bit in PASM have worked with it. One has to know quite a bit, just to get started.
What I mean by presentable is that the material needs to be created for new users that haven't acquired years and years of programing experience. I started with the BasicStamp in 2004, and before that I just took Fortran on an IBM360 in about 1969.
Exactly, why advertise Forth as running at assembler speed if you are actually using assembler to get the job done?
That how one gets assembler speed, no? C compiler generates executables out of source does it not? Isn't that assembly instructions? Or did I miss something again?
No idea what that means "and executed at nearly assembler speed". Even if it only took two asm instructions to implement every Forth word that would be half as fast. I'm sure it must be an order of magnitude worse that that even for simple operations.
OK, I'll tell you. Ultimately, all the forth words are implemented in assembler. Like + is "add", @ is some memory move, etc. To call these, forth makes a jum to the assembly, then a return after. So the assembly that implements + only appears in one location, every subseqent use of + is by a jump and a return. That's the "forth" over head. So its assembly, strung together with a bunch of extra jump and returns. So in forthm, the assembler carries this tiny overhead for the jump and return mechanisms, but otherwise it is assembler. Pretty neato, I think. Anyway, your guess was close, but you didn't think it out and refine it for 25 years, so you missed it by a little.
@prof_braino, I modified my code so it would run under PropForth, and it ran at an equivalent baud rate of about 6,500. That's about half the speed of PASM pfth. The 230,400 baud that you quoted must be from the assembly routine that mindrobots described, and not from a bit-banging Forth routine. I was rather surprised to see that PropForth doesn't support WHILE. That's a very basic and commonly used word.
The basic run of thumb is "get it working quickly in forth, make execute FAST in assembler". ALL the executing is in ultimately in assembler. The forth is the wrapper that make it interactive. This is the nature of the tool.
While is a common word, but very expensive. Many words, like PICK and ROLL, are not recommended for microcontrollers, and are only for systems with too much processor speed, and too much memory that would not be used otherwise. I belive the WHILE is in this catagory, if begin... until and do...loop are done correctly, we really don't need them in the kernel, and can be left as extensions.
I agree that assembly should only be used if you really need the speed performance. It's much more efficient to write in a high level language when speed doesn't matter.
As far as implementing WHILE and REPEAT they are so simple that I don't understand why PropForth wouldn't include them. In PASM pfth they are implemented as follows:
: while r> ['] _jz , here >r 4 allot >r ; immediate
: repeat r> ['] _jmp , here 4 + r> ! r> , >r ; immediate
PICK and ROLL aren't necessary, but if you can implement them why not provide them? pfth implements PICK and ROLL as kernel words, and then implements DUP, ROT, etc. using PICK and ROLL. This way I only need two kernel words to manipulate the stack. I could probably get by without having PICK and ROLL, but then I would have to implement more kernel words. I did use PICK to implement the _jz word, but I have since made that a kernel word. I also use PICK to implement the .S word. I could do it another way if I provided a variable that gave the stack memory address.
I'm not really suggesting that PropForth implement these words. I understand that you and Sal have no interest in porting code that uses those words, so there is really no reason for PropForth to support them.
Hi Dave,
Since someone might argue that there is no reason to implement such words as space in the dictionary is especially limited.....
I will mention that PropForth provides some unnecessary bloat.
In the test lexicon in the ProfForth.htm v5.03, it has
0<= and 0> when 0> is all that is required.
One cannot claim to be a minimalist and defend having two words for one function, or using 3 characters when 2 are adequate for a word's name. There are other instances for synonyms ( not homonyms... my error), but they are more subtle. ( I believe most of the other synonyms are used as constants.)
I would say that one should consider becoming more open-minded to suggestions and collaboration. But it seems that we have to respect Sal's judgement is such matters as superior.
On the other hand, there are many ways to describe looping behavior. And I do suspect that ANS Forth 94 includes redundancies of its own. But at least it never defends them with mere rhetoric. PropForth seems to provide services for definite loops, and indefinite loops with or without testing. I suspect that is enough to allow a complete suite of looping services.
To put it simply, PropForth does have some bloat. In other instances, it may attempt to be minimalist. And it even has a few glaring oddities ( such as the word _ecs for providing for an <esc>).
These are only the simplest and clearest of examples. I wish we could get past all this defensive posturing and just have real dialogue. There are items that might be improved.
That how one gets assembler speed, no? C compiler generates executables out of source does it not? Isn't that assembly instructions? Or did I miss something again?
Yes, you missed something.
When I write C code it compiles to native instructions. If I include assembler instructions in my C code (inline asm or separate asm modules) then that is no longer C.
Ultimately all programs are running as machine code, there is no other way.
Could be a high level language compiled down to sequences of instruction, e.g. C/C++.
Could be an interpreter compiling source code or byte codes to sequences of machine instructions at run time e.g. (Java and its JIT)
Could be an interpreter selecting sequences of instructions to run depending on the source code or byte code e.g. Spin.
None of that matters to the language point I am making. If the source code of your program, the stuff you actually have to type in, contains architecture dependent machine operations written in an assembler language style, e.g. "add a, b" then you
are no longer writing in that high level language but rather in assembler.
Unless you say that your high level language also include the semantics of every architecture it runs on now and will ever run on then those assembler parts must be a different language.
Therefore If you are advertising that Forth as fast as asm, but that speed actually depends on writing assembler, then your claim is false.
Comments
No, you are mistaken. There are over 300 people involved here. This is based on the number of downloads.
http://code.google.com/p/propforth/wiki/PropForthDownloadStats
The current release has over 300 downloads, and the previous release v4.6 had over 300 downloads.
You and anyone else may interpret the data differently; for my purposes we will assume there are at minimum 300 engineers that may at some point wish to look at the references. This is like any other very large project, it is under estimated by two orders of magnitude.
That being said, it is correct to say it is underfunded.
Google 64 bit encoding, and look at radix 64. This has nothing to do with how the part represents values, it is about how many characters are used to represent values. This is an old technique used to minimize the number of bytes needed for storage or something.That is, it you use ascii characters to represent binary digits, each bit needs one byte to represent it. If we use HEX, we can use 0-9 and A-F. If we use base 64, we can use 0-9, A-Z, and a-z. Peter entered a bug about this, complaining that the NUMBER function accepted characters past 'F'. In fact this is by design to accommodate that maximum number base possible, it is not a bug at all.
This is another thing that has to do with packing the assembler optimized code. It is very easy but not until we get to that point. Save this for February.
The concept is that the download is self contained, but auxiliary resources are on the google code site.
Since the Propforth.HTM file is alway locarted in the same location in the download archive, I asked Sal to provide local relative links from the entries in section 9 to the txt and .f source code files that define each forth word. I won't know if he can do this till he gets back from his travels.
In the meantime, I tried to put a copy of Propforth HTM on th wiki, so we could access it from a browser without having it on the local hard disk. This is necessary for obvious reasons.
The goal is to have the propforth htm file available as a webpage on the internet, and be able to click on each word (in section 9), to display its source code.
Of course, google code did not like me pasting the raw HTML into a google code wiki page, and locked up the file:
http://code.google.com/p/propforth/wiki/Propforth_htm
So I made another copy and just pasted in the rendered text.
http://code.google.com/p/propforth/wiki/PropForthHtm
This is proving to be a big effort to re-edit the text. I haven't even gotten it to display correctly, let alone add all the anchors so we can click through links to the source.
Anybody have advice on an easier way to do this?
Your '64bit optimized assembler code' is not really 64bit assembler code. It seems to be conventional 32bit Parallax Propeller assembler code that has used some Google 64bit algorithm to tightly pack it in the dictionary space.
And I should wait until February for an explanation. ... or something.
That's interesting.
Now that I have your attention.....
I looked at the .htm entries for serial and _serial. Can you assure me that they were designed in a fashion that the rx and the tx pin can be the same one?
I strongly suspect that this is NOT the case. That the serial configuration will crash. And that will be the end of my chopstick printer project on Forth.
Meanwhile I will first try to get a serial loopback working in PropForth at 9600 8N1 and then if I can make that work, I will proceed with my own testing for a possible crash.
If I haven't mentioned it already. the replacement Inkjet cartridge has been ordered. And hopefully it will arrive in time to have an actual printed chopstick.
" That being said, it is correct to say it is underfunded."...Prof Braino
Underfunded? Does that mean you are actually being paid by someone for your efforts? I am intrigued.
i seem to be having trouble with english.
did you do the google thing? it really explains it well, or at least better than me.
also, i meant it will not be until february until you can understand what the more advanced stuff is about.
if you don't read the material, it will take a little longer
no. this is incorrect.
no, the opposite. we have zero funding.
read htm - look at code - try example - ask
if you skip a step it takes longer
"No, this is incorrect."
Does that mean ......
A. YES, I can use the same pin for RX and TX in the 'serial' word
B. NO, I must use separate pins for RX and TX in the 'serial' word
If YES, I then need to check the RX buffer for a prompt before a TX is initiated.
And I need to clear the RX buffer after each check. I am beginning to see there might be a way as long as I clear the RX buffer at certain times. The prompt is a > and with the shared TX/RX pin I may fill the buffer with CR or CR/LF that will have to be dumped or ignored.
I might be able to do the following...
1. clear the RX buffer
2. send a CR/LF
3. check the RX buffer for 'CR/LF >' sequence and interpret that as a ready for reception condition.
4. transmit a string of data
5. go back to #1 above.
When I look into the source code for 'serial' and '_serial', such details appear to be coded on assembly language. Rather than try to explain the hardware details again, I am providing a link to the document.
http://www.parallax.com/dl/docs/prod/robo/InkjetKitDocs-v1.0.pdf
If I can verify the RX buffer, I can use FILL to make it all zeros.
I re-read Chapter 6 of the PropForth.htm and located the io word. It seems that is equivalent to sc par COG@ . when the console is active in any given cog. So this I am presuming is the origin from which the RX buffer and TX buffer are offset as mentioned in serial and _serial.
In other words, I have found a working hypothesis for clearing the RXbuffer. And so, tomorrow I hope to sit down again and re-read the Chapter 6, all the serial and _serial information and the 3.2 serial loopback with some testing of RX pin equal to TX pin configuration. I have read the SERIAL wiki as well.
If I can at least get the second Serial port up and running, I may work out the rest of the details.
I am hoping the ink cartridge will arrive tomorrow and I still have to bench test the two 5 wire stepper motors through a rotation sequence.
~~~~~~~~~~~~~~~~~~~~~~~~~
Arg.... I hit another snag in one pin bi-directional. The pin i/o will have to be toggle between input and output. Lucky that I thought of this.
I think that will nicely complete the sequence I mentioned of clearning the RX buffer
1. Set the Serial shared RX/TX pin to pinout
2. Clear RX buffer by filling with zeros
3. Send a cr or a cr/lf (as required)
4 Set pin to pinin
5. verify that a cr > or cr/lf > have arrived
6. Set pin to pinout and wait
7. Send whatever coded string is requried to print, such as <STX> some text <ETX>
8. Wait for print head to complete its output
9. Go back to number 1
Either that will work or I am just chasing rainbows. Yes there is an extra set pin to pinout in there. I am thinking about having two entry points to this loop. One is for me to start the process, which is at #1 and a second at #7 that is triggered by data arriving in the TX buffer. I am not sure if this is silly or wise at this point.
Regardless of pinin or pinout state, the single pin will be an active loop back between the two buffers at all times.
Success may depend on how fast the pin can be switched between pinout and pinin and back again as the Serial Inkjet Printer Board may not have any delay in response with a prompt. I have to check that code for available delay.... and maybe add a longer delay in the SX28 code.
thus your confusion.
It means "it works the ways it works, you start by figuring that out, and decide how to change it to do what you want". Which is not as un-helpful as it sounds.
The provided serial examples are designed to talk on one pin and listen on another, and to have the mechanism running continuously. What you appear to need is TWO SEPARATE words, one to talk, and the other to listen. Instead of continuous, you want them bounded by bytes or timing. And your application will alternate calling talk and listen. I haven't done this yet, but you should be able to take the example, and use it as a starting point for your talk and listen words.
Hi,
I do acknowledge that I seem too needy from your point of view. Hopefully we can change that and go foward.
On the other hand, it just could be more un-helpful that you can see. I just wanted to know if the serial and _serial support a half-duplex configuration. Without support in the assembler code, it just may be a complete waste of time.
A word search of the PropForth.htm only has full duplex mentioned in discussions of the MCS and nothing in the Serial feature. There is no mention in the text of half-duplex anywhere.
There are occasions that everything is NOT in the .zip file source code and documents. I seem to have come across one of those. Try your word search of the PropForth documents for full-duplex and half-duplex or full duplex or half duplex or duplex.
And this appears to be one of those situations where something was not included.
Since Sal Sanci is only available to you, I turned to you due to the time element in this little contest, but I guess the only real channel of communication with Sal Sanci is to post a Issue report in the Google PropForth.
It is very likely that this cannot be resolved in the time frame of the contest. I am okay with that. I have learned quite a bit. The PropForth serial function is quite interesting, and it also has some very real limitations.
Okay.....
Let me clarify exactly what 'works the ways (sic) it works" from my view point.
1. I need half-duplex RS232 and PropForth seems to provide only full-duplex RS232.
2. I cannot locate anything in the documentation that claims the Serial code is able to reconfigure from full-duplex to half-duplex. It seems that is buried in Assembler code. I cannot even confirm that the serial driver is full-duplex, but it seems to behave like full-duplex and the MCS is claimed to be full-duplex.
3. I simply have two choices -
A. Abandon PropForth as it doesn't provide adequate serial port functionality to use with some Parallax products (the Serial Inkjet Printer Board is a Parallax product). At this time, I am not up to writing a PASM full serial suite for PropForth.
Or
B. Try to manipulate the serial port in ways that were never considered by the developer to make half-duplex bi-directional RS232 serial work with the full-duplex code provided in this instance.
In sum, it seems that 'it works the ways it works' is your way of saying.... "No reply, read what's available, and sort it out on your own".
WILL DO, OVER AND OUT.
See, I do understand. I won't bother you with more PropForth questions as I seem to have gotten ahead of you.
But I DO advise you and Sal Sanci to consider documenting for V5.03 that your serial support is only for one type of RS232 and that it is full-duplex 8N1 at a variety of baud rates that are unspecified. The user will have too write a replacement driver for 'serial' and '_serial' if they need other choices or develop a hack on their own.
On the other hand, ever since the BS2, Parallax has tried to provide complete RS232 support in the full suite of configurations. So that makes PropForth as it exists in V5.03 a less useful serial support device.
Everybody starts with 8N1 when they provide serial, as it is the easiest and most compact driver to provide. But at times there are requirements for parity, hardware handshaking, and software handshaking. I do understand that this is minimalist Forth, and 'more is less' and 'less is more' and so on.
But functions are features are utility. More serial options, more people will use PropForth.
Tachyon Forth provides half-duplex, so I may have to switch over to it for this project.
Person writing codes for Propeller-chip is few.
And Forther for Propeller is very few.
I had wrote junk-codes from v2.7.
But almost nothing replys.
But I'm fine, because I like to write forth-codes.
When PropForth doesn't provide functions you desire, I think you should write your desired codes.
If you don't know how to write codes, you should write questions in this thread.
I don't have known RS232 well and written its codes. I can think its code together.
Selection Tachyon Forth might be successfull.
But when Tachyon Forth doesn't provide functions you desire, you switch to other Forth?
Thanks for your reply.
At this point I am not certain that I could write a good serial support for PropForth. I just don't have the skill and experience. But I am enjoying PropForth and may be able to do so one day.
RS232 serial ports are very handy with the Propeller for working with all sorts of old and odd equipment. But there are lots of choices for configuration. As PropForth is now, it only provides 8bit, no parity and 1 stop bit at various baud rates (maybe any baud rate in a range). And it is full duplex.
It will take time for me to write something and we have a little contest that is supposed to have something finished by Nov 25th, (at least I think that is the deadline). I am probably not going to make it, but it has been very useful to learn about the limits of the serial connections.
I will keep studying PropForth and try to improve.
The main point is that the user needs to know when something isn't provided just as much as what is provided. So far several words that are very useful in other Forth are not available, also there is not clear support for creating arrays, and now I discovered that only 8N1 full-duplex, no hardware handshakes, no software handshakes are supported.
These thing are all features that users might want and will look elsewhere if PropForth doesn't have them as it might be faster to learn another version of Forth of the Propeller. I'd like to see PropForth succeed in becoming one of the best.
I don't really want to change to Tachyon, but if I cannot connect with the board I am using, what choice do I have? Spend weeks studying PASM and writing a new serial port via reverse engineeirng? Or just give up Forth?
The software must serve all sorts of hardware to be successful. The easier it is to learn, the more popular it is as well.
Each HALF of the communication is HALF duplex. One Talks, the other Listens. Your mission, should you decide to accept it, is to make a separate word that talk on the transmit pin, and a separate word the listens on the RX pin. However, if you do not accept this mission, your project will delf destruct in 5 seconds. Good Luck, Mr Phelps.
Your assessment of the need for assembler support is incorrect. As you can see from the source code and the example(s) (you really, REALLY got to read the materials and do the exercises to learn the stuff. A teacher told me this. Ask a teacher if this is true.) the serial is implemented in regular, plain old high level forth. This can do 9600 all day long and not break a sweat. We only need the optimized serial when we need to faster than 57600. At that point we can go 3 million baud as Peter has shown, but Sal de-rated it since he noticed a stability issue in one test over very long distances (but he might have tripped over the wire or such) and we do plan to do the really high throughput over MCS and Ethernet.
I don't want to come off as snippy or condescending, but I have mentioned this reading the materials on more than one occasion. Reading Starting Forth is great to learn about Forth in GENERAL, but is pretty useless for using any forth in particular, except the orignal polyFORTH (from Forth Inc) for which it was written, and possibly Dave's pfth, although I pretty confident there will be significant difference between Brodie's examples and the standard (described 20 years later) at some point in the book.
To learn propforth, you have to concentrate on the function you are trying to make function. Do not worry about all the dictionary structure, threading model, assembler, optimization etc until you get there. Look up the word in propforth.htm, look up the word in the source code, try the examples, and run the tutorial. If you don't do all these steps, you have a decreased likelihood of success.
There rest of your post is not really actionable until you have done the reading and exercises. If you wish to abandon propforth, so be it. Perhaps propforth is not a suitable tool for your purposes.
This is correct. Stuff that was determine to be "not needed" receive no effort. Think about it. How big would the kerenl be if we tried to implement every possible permutation that no-one will ever use? We would have Windows. Sorry, that won't fit is 32k. Maybe 640k?
This is unfortunate, but you misunderstand the relationship.
Notice that you are the only one who has mentioned half duplex support and documentation. Who should do this work?
We get to use Sal's tool, because he's nice and shares it with us at his pleasure, with no obligation. Sal will NOT do your homework for you, no one may make any demand of him for any reason whatsoever. You ask nicely or are ignored. This is why he does not respond to the forums. People can get exited and neglect decorum. Sal does significant work at my request because I ALWAYS take great effort to only ask for things that greatly overlap his work in progress. Requests further from this model are less likely to be fulfilled quickly.
I have no intention of being someone's Forth groupie with Sal as my 'master' and you as the 'keeper of the flame'. I may continue to use PropForth, but my expectations have been substantially lowered.
The thing is that you keep throwing back inquiries of what is and what exists by saying that I am asking for something that I should create or document or waste time searching for in a fashion that is unclear.
The net result is the very real experience that PropForth is trying to be something it isn''t.
I have never expected Sal to 'do my homework for me'. And that is you speaking, not Sal. There are real and obvious absurdities in the liberties you take in speaking for others. If and when Sal has something to say to me, you can give him my email address.
I don't have halfduplex-hardware.
Your device's signal-line is only one?
Are there anymore line?
Please be clear hardware-spec(speed,stop-bit,parity,etc).
Wow. Little confused by this over here, the conversation keeps going further in the wrong direction. I've been trying to keep responding to the threads while doing other responsibilities, it looks like the communication has fallen apart.
So, you don't want to examine the code, and you don't want to work through the examples? I'm not sure what else to recommend. As far as I know, that's where we have to start. If this is unsuitable, I'm limited in the help I can provide. I can try to answer questions as best I can, but I just do docs and testing, so I can only go so far with the time I have available.
I'm not sure where the 'master' and 'trying to be something it isn't' is about. Propforth is just a tool. There's code that functions correctly, and examples that show the correct operation of each function. That is the resource available to us. Each function only does what it is intended to do; if we wish to change that, we take this task upon ourselves. We can change anything we want to extend the tool in any direction we choose. The kernel is just a starting point.
Don't give up on Forth, there are others options. The competition dead line did not give much time to get a project up and running. .I started to port and upgrade the old "Dr Elisa " the AI game from years ago. It is to run off a SDcard but its not going to get finished for this comp.
I believe there will be another comp next month. Thanks to Peter Rick and Co.
I know what you mean about Propforth, but Sal choose not to participate in the forum, that's his choice. One of the good things to come out of the gcc project is that we will have an ANS Forth running on the Prop, thanks to Dave Hein. I don;t think it will be the last. .
It's an ANS Forth and it looks like it's really fast. I have had a play with the C version. It is so easy to install.. It runs in a shell so you can install any flavour you like ansi.fth, ansi3.fth of if you must, you can even roll your own (DONT TRY IT) . You don't have to know anything about C. There are also words in the starting.fth file which you can install which allows you to do the exercises in the Starting Forth book.
You can also look at this tutorial. 27 pages mostly ANS standard.but is written for beginners to pforth( portable forth)
www.softsyn.com/pforth/pf/tut.php.
Once you are comfortable in forth its not too difficult to move to Tachyon of other specialist versions. Tachyon looks like it's tailor made for you project.
Send me some chop sticks when your project up and running, I used them for eating amongst other things for two years or more when we where in Pula Penang.
Keep pluging away Propforth Tachyon, mv4th,JDforth, or ANS forth, which ever you are comfortable with. The tutoral above is worth a look.
Ron
Link don't work for me
There is a space between /pf tut.php
^
lets know how you go
Sapieha
and click on Tutorial
Ron
Hi Caskaz,
It is nice to hear from you.
Yes I have only one wire, it is bi-directional. I attached a file with complete documentation of the board in the above threads. But it might just be simpler to explain. The board is a Parallax product that was made for Hewlett-Packard and they used these to support there industrial side of Inkjet Printers. It is used to apply expiry date stamps and batch codes in automated packaging. So I am not using something that is not in normal commercial use.
Communications require half-duplex 9600 8N1. PropForth may be able to handle this on two wires quite easily, but one-wire is something a bit more difficult.
The board could be said that it acts as a slave.
There is a bit of handshaking. If I send a CR, the board sends back a > to show that I have an active line and that it recognizes the serial baud rate. I can do this without using PropForth, so I know the board works.
After that I can send a <STX> up to 64 ASCII characters <ETX> and the printer head will print all of them.
And then the board sends another > to me to tell me it is ready again.
I have studied the Tutorial 3.2 for Serial Loopback. It is quite complex as it used 5 cogs to do something that I had thought should require only 1 cog. I still don't understand all the code in the 'term' word and there is no explanation of that words. In fact, it is a bit unclear as to why 2 and 0 are put on the stack before it. I guess these are cogs tied to an RX and a TX.
There is also a word to set the serial flags, but how many flags there are and what setting them does is not explained.
There are also words for making io connections and links internally, but not much is said about any of these. So I am pretty much on my own to dig all this out.
The whole idea of these forums is share knowledge. But like you, I am forced to just dig up answers on my own. I feel rather buried in code at this point without any overview from people that might be able to provide overview.
So I try to create my own overview and summarize what I've discovered. Some people say it is very helpful, others say I am wasting time asking questions.
I do now understand that your time is limited and the docs are rather limited.
The other stuff is merely a product of frustration as it had seemed that the documents were further along than they are, and several other misperceptions.
I can adjust.
I have worked through the Serial Loopback Tutorial and it works. But there really is no explanation of why. It is very WYSIWYG. It works, but I don't see how to apply any of what it demonstrates in any useful way. Five cogs for a loop-back is a lot of real estate for one function.
I can go from word to word digging out meaning on my own, but I thought there was some mutual benefit to be gained in collaboration. I submitted a rather long list of writing tasks that I had accumulated.
Thanks Ron,
I actually do like Forth and think it can be a lot of fun. For the past 18 years I have almost never seen a fork, knife or spoon. Chopsticks for everything here.
In fact, I think we all really like Forth. It is just that it seems that getting it into a presentable fashion for use on the Propeller will take some effort. As it is, mostly people that can handle coding quite a bit in PASM have worked with it. One has to know quite a bit, just to get started.
What I mean by presentable is that the material needs to be created for new users that haven't acquired years and years of programing experience. I started with the BasicStamp in 2004, and before that I just took Fortran on an IBM360 in about 1969.
That how one gets assembler speed, no? C compiler generates executables out of source does it not? Isn't that assembly instructions? Or did I miss something again?
OK, I'll tell you. Ultimately, all the forth words are implemented in assembler. Like + is "add", @ is some memory move, etc. To call these, forth makes a jum to the assembly, then a return after. So the assembly that implements + only appears in one location, every subseqent use of + is by a jump and a return. That's the "forth" over head. So its assembly, strung together with a bunch of extra jump and returns. So in forthm, the assembler carries this tiny overhead for the jump and return mechanisms, but otherwise it is assembler. Pretty neato, I think. Anyway, your guess was close, but you didn't think it out and refine it for 25 years, so you missed it by a little.
The basic run of thumb is "get it working quickly in forth, make execute FAST in assembler". ALL the executing is in ultimately in assembler. The forth is the wrapper that make it interactive. This is the nature of the tool.
While is a common word, but very expensive. Many words, like PICK and ROLL, are not recommended for microcontrollers, and are only for systems with too much processor speed, and too much memory that would not be used otherwise. I belive the WHILE is in this catagory, if begin... until and do...loop are done correctly, we really don't need them in the kernel, and can be left as extensions.
As far as implementing WHILE and REPEAT they are so simple that I don't understand why PropForth wouldn't include them. In PASM pfth they are implemented as follows: PICK and ROLL aren't necessary, but if you can implement them why not provide them? pfth implements PICK and ROLL as kernel words, and then implements DUP, ROT, etc. using PICK and ROLL. This way I only need two kernel words to manipulate the stack. I could probably get by without having PICK and ROLL, but then I would have to implement more kernel words. I did use PICK to implement the _jz word, but I have since made that a kernel word. I also use PICK to implement the .S word. I could do it another way if I provided a variable that gave the stack memory address.
I'm not really suggesting that PropForth implement these words. I understand that you and Sal have no interest in porting code that uses those words, so there is really no reason for PropForth to support them.
Since someone might argue that there is no reason to implement such words as space in the dictionary is especially limited.....
I will mention that PropForth provides some unnecessary bloat.
In the test lexicon in the ProfForth.htm v5.03, it has
0<= and 0> when 0> is all that is required.
One cannot claim to be a minimalist and defend having two words for one function, or using 3 characters when 2 are adequate for a word's name. There are other instances for synonyms ( not homonyms... my error), but they are more subtle. ( I believe most of the other synonyms are used as constants.)
I would say that one should consider becoming more open-minded to suggestions and collaboration. But it seems that we have to respect Sal's judgement is such matters as superior.
On the other hand, there are many ways to describe looping behavior. And I do suspect that ANS Forth 94 includes redundancies of its own. But at least it never defends them with mere rhetoric. PropForth seems to provide services for definite loops, and indefinite loops with or without testing. I suspect that is enough to allow a complete suite of looping services.
To put it simply, PropForth does have some bloat. In other instances, it may attempt to be minimalist. And it even has a few glaring oddities ( such as the word _ecs for providing for an <esc>).
These are only the simplest and clearest of examples. I wish we could get past all this defensive posturing and just have real dialogue. There are items that might be improved.
PropForth has warts. It is just that simple.
Yes, you missed something.
When I write C code it compiles to native instructions. If I include assembler instructions in my C code (inline asm or separate asm modules) then that is no longer C.
Ultimately all programs are running as machine code, there is no other way.
Could be a high level language compiled down to sequences of instruction, e.g. C/C++.
Could be an interpreter compiling source code or byte codes to sequences of machine instructions at run time e.g. (Java and its JIT)
Could be an interpreter selecting sequences of instructions to run depending on the source code or byte code e.g. Spin.
None of that matters to the language point I am making. If the source code of your program, the stuff you actually have to type in, contains architecture dependent machine operations written in an assembler language style, e.g. "add a, b" then you
are no longer writing in that high level language but rather in assembler.
Unless you say that your high level language also include the semantics of every architecture it runs on now and will ever run on then those assembler parts must be a different language.
Therefore If you are advertising that Forth as fast as asm, but that speed actually depends on writing assembler, then your claim is false.
Or am I missing something?