View unanswered posts | View active topics It is currently Thu Jun 27, 2019 6:12 am



Reply to topic  [ 8 posts ] 
 what is v4th? 
Author Message

Joined: Sat Jul 19, 2014 12:22 am
Posts: 5
Hi again, folks. I have taken up Jeff's (Dr. Jefyl's) suggestion, and am attaching a brief description of v4th, for the amusement any Forth aficionados.

This doc has a blatant self-promotional agenda, but I hope I didn't lay it on too thick... Please don't take any offense.

cheers, - vic


Attachments:
v4th_precis.txt [6.34 KiB]
Downloaded 418 times
Tue Jul 22, 2014 3:42 pm
Profile

Joined: Sat Jul 19, 2014 12:22 am
Posts: 5
PS there is no word-wrap, so you'll need a text-viewer that provides wrapping.


Tue Jul 22, 2014 3:56 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1192
Thanks for posting. For accessibility and search here are the first few paragraphs:
Quote:
What is v4th? v4th is a Forth-like programming framework for embedded microcontrollers. Since its first version on the RCA 1802, it has been used to build many successful products, and ported to a wide variety of CPUs over the years, with continuous evolution and improvements. Today, versions exist for MSP430, MIPS, RX, and various flavors of ARM targets.

v4th is not Forth -- not quite. It only runs an "inner interpreter" engine, and thus has no interactive console, native compiler, nor its own IDE.

Then why use it?

Just like Forth, v4th uses a dual-stack Virtual Machine and nested definitions, and allows you to use the same design methodology and programming techniques as Forth.

v4th is intended for embedded turnkey systems that are purpose-built machines, where user-programmability is undesirable and inappropriate. Nevertheless v4th is completely "open"; an experienced MCU jockey can easily modify the software at will.


Tue Jul 22, 2014 8:19 pm
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 264
Location: California
I have thought about doing a STC Forth where the level of performance versus memory can be chosen at compile time. If the code for a word is no longer than a subroutine call to it, it would always get straightlined, and of course the longest words would always be called; but in between, the optimization level specified would be evaluated along with a number associated with the word to determine whether to straightline it or call it as a subroutine. The optimization level would not have to be the same for all parts of the code.

My 65816 ITC Forth has several hundred primitives though, including optimizations you mention, like DUP >R. Why DUP it first and then require >R to drop it. So there's a primitive to do it with fewer machine-language instructions. Since it is used so many times, the word to do it pays for itself in code space while improving performance. With a good instruction set and registers wide enough to handle an entire cell at once, a lot more things can be done as primitives, so NEXT gets called relatively few times to get a job done. Where a machine code section is desired inside a secondary (ie, colon definition), use INLINE <machine_code> END_INLINE <cont_in_high_level_Forth>. There has been a ton of attention over the years at optimizing NEXT, trying to squeeze out one more cycle here or there, and yet words have not been optimized to reduce the number of times NEXT gets run.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Tue Jul 22, 2014 8:46 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
Garth wrote:
There has been a ton of attention over the years at optimizing NEXT, trying to squeeze out one more cycle here or there, and yet words have not been optimized to reduce the number of times NEXT gets run.
Good point! -- one that you & Vic both seem to have addressed.

vapats wrote:
ToS (and typically also NoS) are cached in CPU registers, instead of being held in RAM.
Can you elaborate, Vic? In the conventional arrangement, when NEXT executes, the outgoing and incoming words contain certain things in certain registers -- always. IOW there'd be a specification that you must always cache NoS or never cache NoS. But you've arranged some variability with that? Or have I taken the wrong meaning?

cheers,
Jeff

_________________
http://LaughtonElectronics.com


Tue Jul 22, 2014 10:10 pm
Profile WWW

Joined: Sat Jul 19, 2014 12:22 am
Posts: 5
@Ed; thanks for adding that. That's a forum nuance that I didn't anticipate.

@Garth; yes, exactly. People who /use/ Forth have a different view than people who have /implemented/ Forth. Often performance must be traded-off for code size, but sometimes you can get a double-win with improvement in both.

@Jeff; well, I recently saw an old FIG-forth for the 8086, where the params were always saved/restored to/from RAM. This simplifies DEPTH and .S, but 99.9% of the code was pretty inefficient. Does this answer your question, or am I missing something?

cheers, - vic


Tue Jul 22, 2014 10:18 pm
Profile

Joined: Sat Jul 19, 2014 12:22 am
Posts: 5
@Jeff; "IOW there'd be a specification that you must always cache NoS or never cache NoS. But you've arranged some variability with that?"

Oops, I think I get what you're driving at... It's question of optimization for each particular architecture. Caching T and N is best for ARM, MIPS and RX, but ToS-only is the hot setup for the MSP430.

cheers, - vic


Tue Jul 22, 2014 10:32 pm
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
vapats wrote:
ToS (and typically also NoS) are cached in CPU registers, instead of being held in RAM.
vapats wrote:
It's question of optimization for each particular architecture. Caching T and N is best for ARM, MIPS and RX, but ToS-only is the hot setup for the MSP430.
OK, thanks. So, for any given implementation, the specification is that NoS is always cached or that NoS is never cached.


FWIW, I can envision a Forth implementation which allows, say, two possible specifications for how things must be when NEXT executes:

  • register A, reserved for caching ToS, is presently full (valid). This'd be the exit condition for words like LIT which grow the stack.
  • register A, reserved for caching ToS, is presently empty (invalid). This'd be the exit condition for words like ! which shrink the stack.

I'll omit the details, since for that I should start a new thread. But the basic idea of the flexible specification is that the incoming word adapts to whatever the outgoing word has left behind -- ie, either ToS resides in A, or ToS resides in memory. The upshot is we would dump A to memory, or fill A from memory, only when needed -- unlike inflexible specifications, which sometimes result in unneeded dumps/fills.

I don't claim that the benefits outweigh the costs, since I haven't evaluated (and there are at least three different ways this could be made to work). I'm just explaining why I found it ambiguous when your doc mentioned V4TH's optional caching of NoS.

J. :)

_________________
http://LaughtonElectronics.com


Wed Jul 23, 2014 12:18 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 8 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software