VFX Forth version 4.7

VFX Forth features common to all versions

VFX Forth for Windows

VFX Forth for Mac OS X

VFX Forth for x86 Linux

VFX Forth for ARM Linux

VFX Forth for DOS

There are new library interfaces to libcurl, libiconv, SQLite3 and zlib. Additional notations have been added to the shared library interface to ease porting of code from other Forth systems.

See our benchmarks.

See the release notes.

 

---

VFX Forth for Windows

Download the latest free trial version.

GTK+ GUI and graphics

fJACK Audio interface

Customer comments
“VfxForth is the most fully featured FORTH I’ve ever worked with. This will be a fun project with lots of tools to work with.”

“I know a lot of compilers are free but speaking freely, this is one of the best darn things I’ve spent money on.”

“GUIgen is the best and most useful bit of code I’ve seen in a very long time.” More about GUIgen

“I just wanted to write and congratulate you on your VFX Forth. What a wonderful system you folks have developed! I recently downloaded the evaluation version of VFX and rewrote a Computational Fluid Dynamics simulation that I had originally written for xxxxx. What a difference! Under xxxxx, a single run of the simulation takes over an hour on my computer. Under VFX, the same simulation completes in less than 4 minutes.”

“I am actually VERY impressed with VFX Forth for Windows’s code generation … you have a fantastic product.”

More …

 

---

VFX Forth for Mac OS X

Carbon MacForth on VFX

Cocoa interface

GTK+ GUI and graphics

VFX Forth for Mac OS X is built from the same code base as VFX Forth for Linux, and includes the same VFX code generator and other tools. There is direct support for Mach-O executable file generation and there is access to all functions in shared libraries such as libSystem or frameworks such as Carbon and Cocoa. See the release notes.

A customer said:
“Besides the amazing optimizing compiler, I love the DocGen documentation system. The easy C interfacing and Genio driver architecture have also been key for my project.

More …

 

---

VFX Forth for x86 Linux

GTK+ GUI and graphics

fJACK Audio interface

VFX Forth for Linux is built from the same code base as VFX Forth for Windows, and includes the same VFX code generator and other tools. There is direct support for ELF executable file generation and access to all functions in shared libraries such as libc is available. See the release notes.

Customer comments
“I am in awe of how fast VFX Linux Forth is. My experience is in the distant past with … and more recently G… so I am not used to the optimized code produced by VFX. Very nice!”

” … impressed by the features of the VFX, and the fact that you have a *REAL* manual.”

Free downloads of the evaluation version are available from the Southampton server. Login as “public” with a blank password. The 32 bit VFX Forth for Linux version is available in rpm and deb packages for 32 bit and 64 bit Linux variants, and a tarball. VFX Forth for Linux is suitable for all x86 32 and 64 bit Linux distributions.

The paid-for versions (Standard, Developer and Mission editions) include kernels for the 386/486 class CPUs used by many embedded x86 systems. VFX Forth for Linux runs very well on lightweight systems such as the Ebox2300 or 3300 family with 300MHz or 1GHz CPUs.

More …

 

---

VFX Forth for ARM Linux

It’s just the same as the x86 Linux, except that the assembler, disassembler and VFX code generator target the ARM. It works fine on all versions of ARM Linux that use the EABI interface (that’s nearly all of them these days), including those for the Raspberry Pi and the Beaglebone Black. Includes a direct GPIO access example for the Raspberry Pi with a bit toggle rate of about 10 MHz using the generic GPIO functions, and somewhat faster using functions dedicated to the peripheral pin.

More …

 

---

VFX Forth for DOS

VFX Forth for DOS is built from the same source tree as VFX Forth for Windows, and includes the same VFX code generator, graphics and other tools. VFX Forth for DOS is mainly used for embedded applications. The PowerNet TCP/IP stack is available. For more details see our PowerNet page.

The version 4 releases are available with the same pricing as VFX Forth for Windows. Contact us for further details.

See the release notes.

Customer comment:
“I continue to be astonished at the quantum leap the VFX software suite has taken from ProForth. It’s been difficult to make the right choices during the conversion, without over-indulging, like a kid in the sweet shop not wanting to miss anything that could be potentially delicious.”

More …

 

---

Boards and Hardware

---

MPE LPC2468 PowerBoard

Designed to supply a computing core for industrial applications, this PowerBoard provides all the standard “computer stuff” so that you can concentrate on the I/O handling. Stackable and robust.

 

Lite cross compilers

---

 

Lite compilers are for Windows only; they run well under Wine and other Windows emulators.

Lite compilers are free of charge and are for non-commercial use only. If you want to commercialise your project just upgrade to a compatible Stamp, Standard or Professional compiler with more features.

Lite compilers are available for ARM Cortex-Mx and MSP430 targets. The target source code is for a small target Forth kernel that compiles directly to target Flash. Compiling on-board directly to Flash allows direct programming on the hardware itself, which is fun, ideal for experimentation and for educational use. The programs can become turnkey applications.

The Lite target is not fully compatible with the PowerForth target supplied with the other compiler editions. The Lite target has changes to reduce code size and for compilation to Flash. It may also change as we have to cope with an increasing range of chips.

In order to support both cross development and on-board programming, the Lite compiler includes the AIDE compiler front end which includes a terminal emulator and an editor, the cross compiler itself, and all source code for the target.

AIDE compiler and target IDE

Despite their small size, the Lite targets are capable of real applications. Duncan Louttit reports:

Attached is a photo of the robot that I used at the inaugural IET robot triathlon competition. I used the beta version of the MSP430 Lite compiler for the software. It had to compete in three events; line follower, drag race and time trial. It came 2nd in each competition and second overall. The Forth system is sufficient for this competition. I ended up with one download for the line follower and drag race and another one for the time trial. If I had had more time, we only had 8 weeks to do the whole thing including design and build the hardware, I could have done much better. The winner used a lot of commercial hardware and library routines for things like the PID controller.

Cortex-Mx

“VFXL is a pleasure to work with.”

The Cortex-M0/M3 Lite compiler is code-limited to 64 kb and RAM-limited to 16 kb. Target device drivers are supplied for the STM32F072B Discovery board (includes MEMS gyros), the STM32F4 Discovery board and the Freescale FRDM-KL25Z board. these are available from most catalogues, e.g. Digikey, Element14, Farnell, and Mouser. The prices below are approximate.

• Instructions
• Getting started
• Windows installer

<!—->

STM32F072B Discovery

STM32F4 Discovery

Freescale FRDM-KL25Z

STP LPC812

STM32F429 Discovery board

 

	UK Pounds	Euros	US Dollars
Approximate Exchange Rate (GBP=1.00)	1.00	1.27	1.72
STM32F072B Discovery	7.00	8.89	12.04
STM32F4 Discovery (F407)	10.85	13.78	18.66
Freescale FRDM-KL25Z	10.32	13.11	17.75

MSP430

The MSP430 Lite compiler is code-limited to 16 kb and RAM-limited to 1 kb. Target device drivers are supplied for the TI Launchpad G2 with the MSP430G2553 CPU. This board is available from several sources including the TI web shop. The prices below are approximate.

• Instructions
• Getting started
• Windows installer

MSP 430 Launchpad

 

	UK Pounds	Euros	US Dollars
Approximate Exchange Rate (GBP=1.00)	1.00	1.27	1.72
MSP430 LaunchPad Value Line Development kit, MSP-EXP430G2	6.17	7.84	10.61

MPE – Compiler feature matrix

December 2015

	Lite	Stamp	Standard	Professional
Full-featured standalone PowerForth target	N	Y	Y	Y
Small standalone Lite target	Y	N	N	N
VFX code generator	Y	Y	Y	Y
All target code in source form	Y	Y	Y	Y
Umbilical target	Y	Y	Y	Y
Multi-tasking	Y	Y	Y	Y
Cross reference tools	N	N	Y	Y
Unlimited code size	N	N	Y	Y
State machine compiler	N	N	Y	Y
Floating point math	N	N	Y	Y
32 bit targets
PowerFiler Unix-like file system	N	N	Y	Y
PID loops	N	N	Y	Y
FAT 12/16/32 file system, SD/MMC	N	N	N	Y
USB driver, core and classes	N	N	N	Y
PowerView embedded GUI	N	N	N	Y
PowerNet TCP/IP stack	N	N	N	Y
Compiler source code (with NDA)	N	N	N	Y
16 bit targets
Bank-switched targets	N	N	Y	Y
PID loops	N	N	N	Y
Compiler source code (with NDA)	N	N	N	Y

I was trying to avoid some work, and stumbled across this post (republished with permission) on one of the LinkedIn discussions. If you are at all interested in software reliability, Les Hatton is someone to respect.

I was lost on LinkedIn (not for the first time) and spotted this discussion.

C v C++. Ah yes, we’ve been debating this for 25 years. C++ is absolutely NOT always better. It is just different.

First of all, the programming language appears to be irrelevant in most empirical studies of injected defect, implemented size and similar behaviour – the most significant factor by a long way remains the quality of the engineers producing the system. However, this disguises an unpleasant truth about OO in general and C++ in particular.

I first studied and published evidence on this in 1997 in IEEE journals. The result of the original studies was a systematic bias in C++ towards significantly LONGER defect correction times. In other words, when you make a mistake in C++, you really pay for it. If the use of C++ led to less defects per implemented functionality, we might be able to live with this but there is no evidence that it does.

Indeed, one of the unpleasant side-effects of the OO paradigm is that it appears to delay the detection of certain classes of defect to much later in the life-cycle where they become really expensive to find and fix, (particularly in embedded systems). For example, in my original studies, the use of C++ increased the cost of finding and fixing defects during system testing by a factor of 4 on comparable systems. Inheritance, (single or multiple) in particular appears to be a defect attractor.

Other promises of OO have failed to materialise. We saw it as producing a universal toolset which would allow us to literally bolt together new reliable systems from tried and trusty components, free of unpleasant side-effect. This has not proved the case. Indeed the component size distribution of C++ systems has exactly the same form (a power law) as C, (and Ada, Fortran, Tcl-Tk, Matlab, Java and everything else I have looked at – see my website for a study of around 60 million lines of code). This turns out to be inevitable from information theory via the clockwork theorem.

So, as I mentioned at the start, it is just a different paradigm – neither better, nor worse. The best advice I could give after 25 years of experiments is to let your programmers use whatever language they are fluent in. If they are not fluent in any, (several years at least), you are in for a rough ride. There isn’t much else to go on because we are not in general a critical or even a scientific discipline when it comes to accumulating compelling evidence.

The seeming irrelevance of programming language is actually a great relief to me. If we even consider the possibility that one symbolic representation of a piece of functionality can be superior to another different representation on average, then we must admit the possibility that a Chinese engineer writing about science in Chinese can be systematically better or worse than a German engineer writing about the same subject in German, simply because of the language they are using. This seems to me unconscionable.

Parenthetically, one last thing you might worry about in the months and years to come is that both C and C++ have undergone a pathologically complicated re-standardisation in the last few years producing standards which no one person can understand, (well I’m damned if I can anyway). Neither have served the embedded system user well since the abstract model of computation in both languages leaves both time and space effectively undefined in the rush to add exotic features of unknown reliability. The last draft of the C11 standard before you have to pay for it is 678 pages, nearly 4 times bigger than the C90 standard which we generally understood. This is still dwarved by the leviathan C++11 standard, the last version of which I saw was just under 1400 pages.

If you add to this that most CS students are now only taught Java in any depth, there is a crying need for more emphasis on education as opposed to technology.

leshatton.org