Author Topic: Too many programming languages?  (Read 4029 times)

0 Members and 1 Guest are viewing this topic.

Offline techman-001

  • Frequent Contributor
  • **
  • Posts: 434
  • Country: au
  • Electronics technician for the last 47 years
Re: Too many programming languages?
« Reply #225 on: October 09, 2019, 08:49:02 am »
I run this sort-of-forth in all my esp32s: "Autodesk Threaded Language Application System Toolkit"

https://www.fourmilab.ch/atlast/
https://www.eevblog.com/forum/microcontrollers/somebody-goofed-up/msg2668650/#msg2668650

Just "nc esp32ip 23" and voilà, c'est magnifique!

George, very nice, thanks for the link!

Every Forth I have seen is different, no two are alike. There really isn't a "standard Forth" in my opinion. Every one is a "sort of Forth".

Even Chuck Moore ( the father of Forth) when asked "what is Forth ?" replied "I can't say for sure, but I know it when I see it".

From the Atlast document:-

... "So what is Atlast? Well...it's FORTH, more or less. Now I'm well aware that the mere mention of FORTH stimulates a violent immune reaction in many people second, perhaps, only to that induced by the utterance of the dreaded word "LISP." Indeed, more that 12 years after my first serious encounter with FORTH, I am only now coming to feel that I am truly beginning to "get it"--to understand what it's really about, what its true strengths (and weaknesses) are, and to what problems it can offer uniquely effective solutions."

"... Atlast™ is a toolkit that makes applications programmable. Deliberately designed to be easy to integrate both into existing programs and newly-developed ones, Atlast provides any program that incorporates it most of the benefits of programmability with very little explicit effort on the part of the developer. Indeed, once you begin to “think Atlast” as part of the design cycle, you'll probably find that the way you design and build programs changes substantially. I'm coming to think of Atlast as the “monster that feeds on programs,” because including it in a program tends to shrink the amount of special-purpose code that would otherwise have to be written while resulting in finished applications that are open, extensible, and more easily adapted to other operating environments such as the event driven paradigm. .."

Compiled fast and easily and running on Freebsd:
atlast-2.0% ./atlast
ATLAST 2.0 (2014-07-04) [64-bit] This program is in the public domain.
-> 2 2 + .
4 -> words

STDERR
STDOUT
STDIN
+
-
*
/
MOD
/MOD
MIN
MAX
NEGATE
ABS
=
<>
>
<
>=
<=
AND
->
 
The following users thanked this post: GeorgeOfTheJungle

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 1807
  • Country: pl
Re: Too many programming languages?
« Reply #226 on: October 09, 2019, 09:01:27 am »
Splendid!  :clap:

How does it compare to the other Forths you use? Is it speedy? Is the binary small-ish? How does the .bin size compare to the other ones you've got?

Edit:
I'd want to use the smallest one I can find, because I'm seeing quite a lot of flash cache misses. That slows down my esp32s.
« Last Edit: October 09, 2019, 01:09:01 pm by GeorgeOfTheJungle »
 #include <unistd.h>
 int main (void) { while (1) fork(); }
 

Offline techman-001

  • Frequent Contributor
  • **
  • Posts: 434
  • Country: au
  • Electronics technician for the last 47 years
Re: Too many programming languages?
« Reply #227 on: October 09, 2019, 10:26:59 am »
Splendid!  :clap:

How does it compare to the other Forths you use? Is it speedy? Is the binary small-ish? How does the .bin size compare to the other ones you've got?

Edit:
I'd want to use the smaller one I can find, because I'm seeing quite a lot of flash cache misses. That slows down my esp32s.

Caveat: I'm a Forth user, not a Forth designer, although I program, I'm not a programmer, I'm a 65 year old electronics technician.

Comparisons.
I can't really compare any two Forths, they're all different. Even the one I use everyday "Mecrisp-Stellaris" has differences between Cortex-M chips, even ones made by the same company due to Flash controller designs, peripheral differences etc.

Speed
It's blindingly fast on this 8 core I7, but then so is Cortex-M Forth running under QEMU.

Binary Size
Atlast on FreeBSD X86: 123072 Bytes, not particularly small.
Picolisp on FreeBSD X86 is 209608 Bytes.
FICL Forth on FreeBSD X86 is 7232 bytes, REALLY TINY. http://ficl.sourceforge.net/
   Ficl is a complete programming language interpreter designed to be embedded into other systems (including firmware based ones) as a command, macro,
and development prototype language.  Ficl stands for "Forth Inspired Command Language".
Mecrisp-Stellaris on 32 bit Cortex-M0 is 16KB, written in Assembly.

General Comments
Documentation: excellent and professionally written
Resources: it has a TON of useful Words for X86 including file operations, maths, geometry etc.
General feel: it feels very well designed and slick, I like it

I have a question or two myself
1. how do you talk to ATlast on a ESP32, I assume you had to write a USART terminal interface ?
2. I assume you use GCC and compile C for the ESP32, then use ATlast  as a debugger for your program ?
 
The following users thanked this post: GeorgeOfTheJungle

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 1807
  • Country: pl
Re: Too many programming languages?
« Reply #228 on: October 09, 2019, 11:01:41 am »
Here it is: https://gitlab.com/xk/esp32_pseudo_forth

If you want to telnet or netcat that's not there, it's a later version I haven't uploaded there. This one works over the serial port only. I can try to update it soon-ish if you're interested. Just let me know.
 #include <unistd.h>
 int main (void) { while (1) fork(); }
 

Offline techman-001

  • Frequent Contributor
  • **
  • Posts: 434
  • Country: au
  • Electronics technician for the last 47 years
Re: Too many programming languages?
« Reply #229 on: October 09, 2019, 11:39:31 am »
Here it is: https://gitlab.com/xk/esp32_pseudo_forth

If you want to telnet or netcat that's not there, it's a later version I haven't uploaded there. This one works over the serial port only. I can try to update it soon-ish if you're interested. Just let me know.

That's very kind of you but I won't need it as I'm pretty much only Cortex_M0 for the next decade or so :)

I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 1807
  • Country: pl
Re: Too many programming languages?
« Reply #230 on: October 09, 2019, 12:55:50 pm »
That's very kind of you but I won't need it as I'm pretty much only Cortex_M0 for the next decade or so :)

I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.

You ought to play with an esp32 asap... Then you'll routinely do many more ncs than screens...

FICL Forth on FreeBSD X86 is 7232 bytes, REALLY TINY. http://ficl.sourceforge.net/
   Ficl is a complete programming language interpreter designed to be embedded into other systems (including firmware based ones) as a command, macro,
and development prototype language.  Ficl stands for "Forth Inspired Command Language".

I'm going to have to try that one.
« Last Edit: October 10, 2019, 08:12:06 am by GeorgeOfTheJungle »
 #include <unistd.h>
 int main (void) { while (1) fork(); }
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3027
  • Country: us
Re: Too many programming languages?
« Reply #231 on: October 10, 2019, 01:07:59 am »
Quote
Whilst I can't presume to speak for Westfw, I feel it's more likely that he believes that you have poor fact retention because I'm the Forth guy around here, not him.
heh.  Pretty much.   And thank you for the kind words...
I hope that what the original poster gets from all these many pages of discussion is that there are a lot of "languages" that have a significant segment of "haters", but are still useful IN SOME SITUATIONS.Not many things hurt worse than trying to shoe-horn some function into a language where it just doesn't belong, just because it's the language you know (or worse, the language your employer forces you to use.)
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4213
  • Country: ch
Re: Too many programming languages?
« Reply #232 on: October 10, 2019, 07:31:27 am »
or worse, the language your employer forces you to use.

DTB is a sort of *language* to describe nodes in a device tree. I know where it makes sense, but PowerPC SoCs (by AMCC) cannot be listed in any valid motivation, besides I do find DTB as unnecessary extra compressibility (which makes things more prone to fail), hence I do not like it, but I am forced to learn and use it.

 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4213
  • Country: ch
Re: Too many programming languages?
« Reply #233 on: October 10, 2019, 07:35:28 am »
I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.

Can you tell me more about this?
 

Offline techman-001

  • Frequent Contributor
  • **
  • Posts: 434
  • Country: au
  • Electronics technician for the last 47 years
Re: Too many programming languages?
« Reply #234 on: October 10, 2019, 12:06:19 pm »
I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.

Can you tell me more about this?

Love to :)

Traditional Forth uses a serial terminal to interactively command (in real time) and upload source to the MCU. The Forth I use on Cortex-M is a traditional but modern Forth which I use traditionally making use of modern applications.

Forth serial Terminal use has a few variations not limited to my description below because anything is possible with Forth.

1. A terminal such as Minicom, Picocom, even Hyperterm in Windows is used to interactively command in real time and to upload source to the MCU making use of  the ASCII serial upload capability of the terminal or a 'helper' program called by the terminal for uploading.
In these cases the source code comments are read but rejected by the on-mcu Forth compiler and End Of Line delays are inserted by the terminal (where supported) to prevent the on-mcu Forth compiler choking on long or complex source. There is usually no handshaking of any kind to use as a alternative to the EOL delays and speeds are often 9600 Baud so that errors and warnings from the on-mcu Forth compiler can be read by the programmer as they occur.

2. A purpose made terminal with on board smarts and file upload capability such as eforthcom is used instead. This special terminal is made especially to suit Forth, and strips the comments from the source, recognizes errors and colors them and/or stops the upload completely at the error , plus waits for the "OK," return from the on-mcu Forth compiler giving the fastest possible upload speed without EOL delays or traditional hardware handshaking.

3. What I use.
I use gnuscreen in my own IDE (which is designed for the fastest possible speed) to do the following:

a. Interactively command the on-mcu Forth in the gnu screen window.
b. upload source to the mcu when I click my editor 'make button'. It does this by opening a remote connection to gnu screen and uploading commands and source via a Makefile. I do all this from the editor window but I see the upload as it occurs in the gnu screen window ... sort off, because at 460800 baud with hardware handshaking its hard to read anything as it flashes up the screen.
c. all comments are stripped from the source by SED before being uploaded in b. above
d. Any errors from the on-mcu Forth compiler are highlighted in RED in gnu screen using a sub-process involving configurable SED keywords and ANSII escape codes inserted into the RX stream. Warnings are coloured BLUE.
Warnings and errors RING the gnu screen terminal bell as they occur. This is all needed because the uploads are to fast to read.
e. Stop the upload at the error if desired. This can be done with a toggle switch at the development hardware. I don't use this nowadays as color errors and the beep of the terminal bell are all I need. Gnu screen has a long history buffer and I can easily scroll back to look for the colored error after hearing a beep.
f. Suck the entire Dictionary from the MCU in IntelHex and build a complete binary image of everything including user Words from a project. This image can then be flashed to another mcu which is then a 100% clone.

Personally I find traditional Forth such as 1. above far,far,far too slow and I wouldn't blame anyone who tries Forth in this way from thinking it was a load of ancient crap compared to using arm.none.eabi and GDB via SWD on a Cortex-M.

I developed my system until it was faster than arm.none.eabi and GDB via SWD on a Cortex-M using the usual write code, try, fix, repeat development cycle.

Only then was I happy.

My system is far more than just gnu screen above as it involves:
1. a project builder
2. integrated Fossil SCM with webserver
3. integrated configurable CMSIS-SVD memory map and bitfield generator for any STM32 Cortex-M mcu. This means I can easily write Forth code as I have every peripheral memory mapped automatically. I never  have to refer to the documentation for memory locations or register bitfields.Doing this manually is tedious, error prone and incredibly slow. No one should ever have to do this and I'm amazed by Forth people who still do this manually on Cortex-M.
 
The following users thanked this post: legacy


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf