Post on 20-Oct-2015
description
: Forth A New Hope
Interactive Systems Programming in the Age of the Pocket Supercomputer
;
Forth is the Future
If we write it
A Problem Oriented Language
A New Set of
Problems
Convergence:
• (FL)ops / W
• Heterogenous Architectures
• Dynamic / JIT Optimization
Forth has two problems…
Cache Invalidation
Naming Things
Validation
• Lack of static typing a strength
• Lack of any typing whatsoever?
• This is a real problem for the user
• Compilers don’t care for it either
Naming
• Words are phenomenally powerful
• Wordlists / Vocabularies are okay…
• This is our highest abstraction at ANS level
• Kiss of Death
These Problems Compound!
Validation Naming *
• No way to convey type information
• Collections of words cannot be handled as a unit
• The result is idiosyncratic code, and no libraries
• Every Forth program is one book
• Every Forth group has their own dialect
Smaller Problemsforth grew up poor.
let’s waste some bytes.
Too Small
• ANS model impoverished by necessity
• Existing implementations miserly with memory
• Forth exists for all 8-16 bit systems
• 32 and 64 are the only numbers that matter
Too Literal
• Anonymous values are hard
— This relates to lack of typing
• Introspection is brittle across versions
• Poor concept of surrounding environment
• Monotonic memory model means missing modularity
Not Literal Enough
• ‘cell’ varies by a factor of 4
• Words for absolute widths are nonstandard
• Floats are a mess
• Unsophisticated I/O model
— These are library problems
• Without modularity, everything is a keyword
A New FIGForth
Implementation Precedes Standards
We Need Forths( we have forths )
One Forth at a Time
A Consular Forth
• Unix Native
• 32 and 64 bit literal
• Full Introspection
• Dynamic Optimization
• Modularity
• Annotative, Inferred Type System
Unix Native
• Hence, written in C
• Uses a file system
• Knows: pipes, ports, files, terminals
• Is good friends with shell and python
• “batteries included elsewhere”
• Provide a rich experience, focus on Forth
Unix Native
• Source with image caching
• Late-binding libraries
• Integrated package management
• Interactive ‘Forth Console’:
— shell / editor / umbilical terminal
32 - 64 Bit Literal
• What it says on the label
• Floats on data stack
• Consistent words for doubles and longs
• Gforth supports 128 bit fixed point: useless
• Counted strings have a cell of count
• Compatible means 32 and 64, period
Full Introspection
• Indirect threading model
• All optimization JITted, in principle
• Compilation is information preserving
• Clean return stack ( stack, rack, bag )
• Full anonymity incl. create/does
Dynamic Optimization
• Information preserving threading model
• Even easy wins done lazily (constant folding, peepholes, inlining)
• Hotspot detection, JITting, etc: faster when it matters the most
• Type information would be helpful here!
Modularity
• Wordlist == Vocabulary
• Books, Shelves, Library
• ISBN number, author, name
• word.:book or book .: word
• Runtime handles loading and freeing
• “Codex”, “Ledger”, “Journal”, “Core”
ISBN?• Just a UUID, SHA-1, etc.
• Version numbering considered harmful:
— a bug-fix for 0.3 when HEAD is at 0.5
— same ‘version’ for several environments
• Put user info in the docstring
• Computers prefer unique numbers
• Peer to peer package management!
URLesque:book:author.de-facto-unique.string/bookname#5c2b3ab0-91b2-11e3-
baa8-0800200c9a66
Forthright
book: bookname
author: author.de-facto.unique.string
UABN: 5c2b3ab0-91b2-11e3-baa8-0800200c9a66
…
require” ./file.forth” \ or on search path
load: bookname as: nickname \ etc.
And Of Course
Types!
Type is not defined. At all.
• Tag All The Things!
• One Syntax To Rule Them All
• Quacking Ducks and Unit Tests
• Turing Complete Logic Layer
• “Objects”. So Many Objects.
Does Forth Need Types?Does a fish need a bicycle?
Contrapositive:
If Forth did not need types, we would not fake them, like this:
!: new-word ( buf off — buf+ off- flag )
etc ;
Fabri
• Assert type and stack effect of all core words
• Infer type of new words on this basis
• Assert what cannot be inferred
• Write your assertion, then write your word = unit test
• “Static”, no effect on running code
Fabri
• “Opt out”: can be removed at runtime
• Or, may be retained and used explicitly
• Warning-only: If Forth compiles it, Fabri compiles it
• Integrated with the JIT: case -> dispatch table etc.
• Hyperstatic and forward only (supports SSA)
Fabri
• Formalizes existing practice
• You can trust the stack diagram!
• Types introduced as needed
• Extensible, interactive
• Override through assertion
• Basic component of runtime for full effect
Ok, But…
Why?
Meet the Epiphany IV• 64 cores @ ~800 MHz
• 32 kiB local memory per core, addressable by all
• 102 GFLOPS peak performance (floats ~10% of logic)
• Flat shared-memory 32 bit RAM model
• Network on chip with absolute routing: two cores may communicate without intermediate action
• 2 Watts peak consumption
• Technology scales to 1024, 4096 cores
Chuck Moore’s Law: joules / op
Epiphany IV
• http://www.adapteva.com/epiphanyiv/
• Programmable in C
• JVM, Ruby, Python: Dead. Toast. Finished.
• Lua is a maybe
• Forth is a leading contender
• GreenArray on steroids
Convergence:
• Interactive console
• Package management
• Type system, testing, continuous integration
• Umbilical development
• Dominate the new paradigm: thousands of heterogenous cores and partially-shared memory
Three Projects
• FigForth “Teen Edition”
—Ficus runtime environment
—Banyan package system
• Fabri: Type engine
• Forge: Interactive Console
BSD Licensed
BSD Licensed
• GPL contaminates image files
• Stealing a compiler is pointless
• “Linking” is a nebulous, harmful concept
• Embedded, Mobile, Microcontrol, “real problems”
• Maximum adoption and industry support
• Presumption of goodwill
So Far
• Er… well I’ve written a bit of a console in gforth
• Registered forth.io
• Pforth exists in 32 and 64 bit editions
• Needs some love and attention
• Fabri has several rounds of hammock time remaining
• Actual development closely tied to Ficus
Discussion to continue on
SVFiG list…