CC-Castle; The best Real-Time/Embedded/HighTech language EVER?

Mijn missie:
SoftwareBeterMaken
Product, Proces, Imago
“CC-Castle”:
About (a stalled hunt for) a new programming paradigma: ‘CC’; experimenting with
the new syntax and semantics to create the ‘Castle’ language.
I had to code syntax-highlighting tools for example-programmes, editor-plugins,
etc. I started to build a compiler using model-based engineering tactics for {our
domain} specific language. I wrote a lexer/parser grammar; build an AST; I
studied LLVM, to use it as back-end. And …
How could I ever imagine I could do that? But it was FUN!
Mijn missie:
SoftwareBeterMaken
Product, Proces, Imago Albert is currently working for Sogeti HighTech. This talk, however, is based on personal research, before
he joined Sogeti; It was an ambitious quest and stalled, a long time ago.
Still, it’s a nice adventure worth telling.
The best Real-Time/Embedded/HighTech language EVER?

Mijn missie:
SoftwareBeterMaken
Agenda
I. Welcome & Me
II. CC? Castle?
III. Application & UseCases (basic; focus)
Code examples (Castle Code :-)
Can I teach you a new langue in 10 minutes (no)
IV. Advanced Castle
A bit more code
V. Compiling Castle
DragonBook in 5 minutes
More code: Grammers
VI. A sudden end
It is stalled …

Mijn missie:
SoftwareBeterMaken
Me?
Apparently, I’m well known … (Source: Klaas’ BIO about me)
’80/90: Silicon Compilers @TU/e (study)
2010: started CC-Castle (research/“sabbatical”)
2011: Column about Castle
‘Modelling is the new programming’
2017: talk about TDD @ 040Coders
2019:me again

Mijn missie:
SoftwareBeterMaken
CC? Castle?
source: My ‘home’ wiki, 2010
CC: Connected Components
New programming paradigma which extent and abstracts the concept of
‘OO’ to a new level. Its basic concepts are component and the connection
between them; they are formalised by ports. Like an object, a component has
internal data and methods. Unlike an object, methods can't call other
component’s functions. They can only be reached via a output-port, when it
is connected to a (corresponding) input-port.
Those connections can only made at a higher level.
Castle:
Castle is an experimental language to introduce and try-out a new
programming concept: CC.
It’s also a ‘domain modelling language’, for the high-tech, high-quality,
‘sovereign software' domain. It should be possible to code flawless
embedded/real-time software; like drivers, compilers and daemon/services.
Nowadays this is typical done in C (or C++). As there is no modern
alternative — like for the application domain.

Mijn missie:
SoftwareBeterMaken
Why CC?
Quality
Current languages give the implementor to much freedom
(S)He may call all (public) methods of all available classes
This can only be controlled by code-inspection
Fact: I tried to rerun/compile Castle tools, 10 yr later.
Every little implementation-change creates an avalanche in the used libraries
With CC, one can only reach/call/use:
Internal code within the Component
Send data/events/steams/… to output-ports
Like one can only act on data/events in input-ports (API)
Compare with a ‘PCB’ and ‘chip/component’
a Or PCB-to-PCB, Rack-to-Rack, System-to-System, etc
The implementor of chip-A can never touch the inside of chip-B
The PCB connects (instances of) chips
• Nor “classes” nor “libs” fulfil this!
FUN

Mijn missie:
SoftwareBeterMaken
Why Castle?
Implement & Play with CC-Concept
Make the ‘best language’ for “sovereign software”
RT/Embedded + Drivers/BSP + OS/Compilers/ToolChains + …
http://mess.softwarebetermaken.nl/
C/C++ is (too) old (sorry). But there is no alternative
FreeBSD used ‘K’ (199*): macro’s to automate/hide ; ‘Kernel-C’
“D”, did fail (more-or-less)
There are many modern languages for applications (Python, C#, …)
There is a new kid on the block: DSL (domain specific languages)
Language & Compiler theory did made progress after 1960!
Our/My Domain:
• RT/Embedded, Compilers/OperatingSystems
• Hugely concurrent systems
• Fault-free systems (Support for High Quality)
MORE FUN

Mijn missie:
SoftwareBeterMaken
Some applications
and some code examples
Highly concurrent
Using CC
Finding primes
High Quality
Can a syntax help to prevent bugs? (YES!)
Model (OS) Drivers
Mijn missie:
SoftwareBeterMaken

Mijn missie:
SoftwareBeterMaken
Sieve of Eratosthenes
https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes
‘Concurrent recursion’ algorithm:
try all numbers, divide by all found ones, or find a new prime
Each Sieve can run concurrent. But HOW
Creating a ‘thread’ for each prime, doesn’t sound solid
Want to a able to run it on (a future) 1k core-CPU
(that is just before my retirement)
Don’t want to code the threads.
I want to ‘model/program’ the algorithm
Real examples are much more complex
This one is probably more efficient with 1 core; that beside the issue
Sieve
on: 5
…Sieve
on: 3
Sieve
on: 2
Generator
[2, 3, 4, …
FinderSieve
on: 104729
Main
Last found
Start
Insert new Sieve and rewire on new prime
$MAX

Mijn missie:
SoftwareBeterMaken
Some code snippets
Highlighted by pigments;
‘castlelexter’ extension (2014; unpublished)
It still has bugs! like “int”
Two (partial) examples
Sending ‘data’ over the wire
Sending ‘event’; using a protocol
A component has “ports”, for
Input; a bit like a cls-method
Output; this is ‘new’
A component-implementation CAN’T:
Touch anything outside
Send data/data to an output
A ‘higher level’ connects out/in-ports
Compare to e.g a PCB with components

Mijn missie:
SoftwareBeterMaken
Castle Code (event style)
EventHandler() on .port
“function” with parameters
Called when its ‘on’ that port
Many handles on one port
• Depending on protocol
Each port has on handles
• Depending on component
C-style body
Some special statements
• See coming slides
Each component is independent
Concurrency is huge
Sieve
on: 2
Generator
[2, 3, 4, …
Finder

Mijn missie:
SoftwareBeterMaken
Castle Code (data style)
DataHandler on .port
Just data
• Type set in component
Only one per port
Called when input changes
• Alternate: stream-port
• Like data, but streaming
- behaviour()
Generic code
Called when a input changes
that is not handle specifically
Also with Events
• See also: -init()

Mijn missie:
SoftwareBeterMaken
Castle code (connect)
Connecting 2 components/ports
A ‘higher’ level: e.g. Main
it has ‘sub’s:
• generator, finder
Create them (like objects)
Connect them
<port> ‘=‘ <port>
• forever “the same”
Both static & dynamically!
Rerouting is possible
E.g.: insert a new sieve
Not shown here
• Ground is: “not connected”
Like None/Null/etc
Sieve
on: 2
Generator
[2, 3, 4, …

Mijn missie:
SoftwareBeterMaken
Quality
Prevent common mistakes
In C:
‘=’ vs ‘==’
In Castle
Not possible; either correct or syntax-error
block-statement always surrounded by {...}
All vars/types/etc are explicit
A bit more typing, prevent creating new variables when mistyping
Syntax in header-files (.Moat) is restricted
Header files are ‘APIs’ & explicated
import/include of .Castle-files is not possible
I know, you take care!
But will the maintenance-team do so too?

Mijn missie:
SoftwareBeterMaken
Special CC statements
Out-ports
Events: “call” event on port
It will “send” that event with parameters out
The “remote” EventHandle will be called
Data: “assign” that port
The value will be passed to remote DataHandler
Connecting ports
Use the ‘=’ (“connect”) statement
It’s symmetrical: left & right are always equal
• For all kind of ports; kind&type should be the same
Boolean/test
Use ‘==’, like in C

Mijn missie:
SoftwareBeterMaken
Bare Metal Modeling
How about software “close to hardware”
OpenSource/Free Operating Systems (kernel space)
BSP (Board Support Packages)
Kernel/Device Drivers
Nowadays, it’s typically done in C (Used to be assembly)
Is it still needed to fill in all the details by hand?
Or can we “generate” the boilerplate C-code
My goal: write drivers in Castle & “Compile to OS”
Mijn missie:
SoftwareBeterMaken
This is an short introduction about the need for this use-case only
There is a lot of work to do to fill in the “details”

Mijn missie:
SoftwareBeterMaken
Kernel/Driver interface [1]
The Kernel->Driver interface is quite simple:
(almost) the same set of functions between Application and the OS
open(), read(), write(), close()
And some special ones, like:
ioclt(), mmap(), etc
When supporting a (hw) device for both FreeBSD and Linux:
Most of the (basic) functionality is the same
Having an implementation for one, it can be “ported” to the other
But, the interface is completely different ….
Can we ‘model’ one (basic) driver …. And
Generate the code for each OS
And for all versions (as this API is not stable; especially in Linux)
Upgrading is not hard, just work > Like to “automate” it

Mijn missie:
SoftwareBeterMaken
Kernel/Driver interface [2]

Mijn missie:
SoftwareBeterMaken
Compile to OS
The basic idea
1. Model/Program a driver is generic (in Castle)
So, Castle should allow everything that is possible in “Kernel-C”
2. Compile the Castle-code in a C-driver for a target
Conceptually, this is very typical for compiler
(Cross) Compile for CPU, OS-details etc
Normally, into ‘assembly’. But C is close to Assembly
Many 1ste generation compilers used(d) ‘C’ as backend anyhow
Implementation
To be done :-)

Mijn missie:
SoftwareBeterMaken
Advanced Syntax
& more
Why use external tools, that generate C, that …
Syntax build into the language
FSM support
Parser support (Scannerless)
Many more ideas
Why use external tools for trial tasks?
Simulation & Queries
“Debug” at high level
Mijn missie:
SoftwareBeterMaken
One special Use-Case:
I need to build a compiler for CC-Castle. And like to use … CC-Castle …

Mijn missie:
SoftwareBeterMaken
Finite -State Machines
FSMs and variants are used often
normal FSM
non-deterministic FSM
Hierarchical FSM
Concurrent FSM
StateDiagram (UML)
A flow-graph is NOT the same
Basically, they are the same
Transformation is posible
States, (allowed) Transitions
Inputs, Actions (=output)
No ‘Memory’!

Mijn missie:
SoftwareBeterMaken
Implementing a FSM is easy
Just a lot of work :-)
So, it isn’t LSD
Dr.Dobb's example:
45 (.h) + 51 (.cpp) lines!
Getting it correct is hard
Boost:
unreadable?
Keeping is correct in very hard!
Adding a State (or transaction)
Results in changes everywhere
How to: diff, code-review, …
Or debug transactions?
Example: FSM in C++

Mijn missie:
SoftwareBeterMaken
FSM in Castle (code demo)

Mijn missie:
SoftwareBeterMaken
Castle’s FSM
States are explicit Declare like vars (kind of enum)
Use at will
Typos’ are “impossible”
Transactions are expressions With optional statement
Input & (current) state, result in new state
Typos’ are “impossible”
Actions: both ‘Moore’ & ‘Mealy’
Moore: in state
Mealy: on transaction
Normal (compound) statement E.g. set an “<out>-port”
Inputs are explicit too
Typical: <in> (data) port Note: ‘events’ are like functions

Mijn missie:
SoftwareBeterMaken
The BEGIN and END state are optional
See below
Statemachines can ‘inherit’
The basic ‘FSM’ defines the BEGIN & END states
Everything CAN be inherited
Use sparingly (default states, trivial transactions)
Like “modern” class inheritance
FSM are (like) ‘classes’
One can instantiate multiple (independ state)
A FSM can contain sub-FSMs (Composite state, Concurrent state, …)
Each ‘state’ is a FSM by itself
FSM-instances &-inheritance come in handy
Define ones. Use often (with actions)
Advanced FSMs (in Castle) [1]

Mijn missie:
SoftwareBeterMaken
There is no need to make the FSM deterministic!
The compiler will transform it
Theory is known for ages!
Warnings are given when needed
Like ‘Lex’ & ‘Yacc’ do
Advanced FSMs (in Castle) [2]

Mijn missie:
SoftwareBeterMaken
Parsing & Lexing
Many ‘add-on’ tools, for the C/C++ programmer to understand text.
Building compilers and stuff.
They generate (C-) code, that is compiled and linked in
(f)Lex, Yacc/Bizon ANTLR, <SDF>, XTEXT
External syntax Some are C-like, others not
Mix-in:
(C-) Code for actions Does not improve syntax-readability
Editor-support & Highlighting is hard
Many tools are ageing (Lex/Yacc: 1975; Flex/Bison: 87/85 !!)
Not OO; (pseudo) Singleton interface (globals)
Old/Traditional algorithms & grammar-syntax
LR/GLR/LALR (bottom-up; unreadable generated code)
Modern insights: LL(*), Scannerless Parsers, ..

Mijn missie:
SoftwareBeterMaken
Parsing in Castle
Writing “compilers” is a UseCase for Castle …
This is still experimental
It was 10 years ago
Influenced by
scannerless/lexerless parsing
SDF, XText, ANTLR
Syntax is like that for the FSM
There is a strong relation between FSM- & parser-theory
Demo (snipped to define ‘Protocol Defnition)

Mijn missie:
SoftwareBeterMaken
Simulation & Queries(intro only)
Surely, one should be able to compile Castle code. But…
A programmer has more needs: “Simulation & Queries”
What data/events ‘go’ over a connection
Use a “sw-scope” to monitor/draw some connection
Put a (debug) alarm on some values
How are ports connected.
What is the Fan-in & Fan-out?
How many ‘hop’s are between an input and an output?
• This gives a hint for real-time behaviour
Does the answer depend on cross-compiled target assembly?
• No! Most can be done with in the abstract moddel
• The timing is different
It’s a lot faster (in dev-time:-)

Mijn missie:
SoftwareBeterMaken
Compiling Castle
(an overview)
The best language to build a compiler:
Castle
And the CC options make it very fast …
However: ….
Its not ready/available
So, implemented with python, ANTLR, and many more
Not ready/done too
Mijn missie:
SoftwareBeterMaken

Mijn missie:
SoftwareBeterMaken
We need code to compile …
Compiling start with code …
By example:
Sieve of Eratosthenes
we have seen it before
Also implemented in:
• C, Objective-C, Go, …
• To compare speed etc
And ends with machine-code
Or: assembly
(& a linker)
Or: C-code
(and CC)
That’s a good way to start
Even C++ started like that

Mijn missie:
SoftwareBeterMaken
The results [1:Proto & Comp structs]

Mijn missie:
SoftwareBeterMaken
The results [2: implement]

Mijn missie:
SoftwareBeterMaken
Etc Etc Etc
Lot of templates/structures to fill in:
protocol Name ☛ struct CC_B_Protocol CC_Proto_Name {…}
component Name ☛ struct CC_B_ComponentInterface CC_CI_Name {…}
implement Name ☛ typedef struct {…} CC_C_Name
Handler on Port {…} ☛ CC_C_Type* <C>Handler<P>(…) {…}
CC operations in de code
Making connections is trivial
Just fill in more data-structures :-)
Reading & Writing/Triggering in/out-ports is easy
Simply handle those data-structures
The rest is commonplace
Just C-code … (more-or-less)

Mijn missie:
SoftwareBeterMaken
Compiler-Architecture
Writing a compiler isn’t that complicated
It has many small steps
Each of them have several tools/options/variants
• lex, flex, yacc, bison, antlr, ply/sly, XText
• StringTemplate[3,4,5], Jinga(2),
Each is a lot of work!
Code
ASM
GCC/
CLANG
C-
CODE
Tokens
Lex
AST
Parse
ATS2
TreeWalk …
…
LLVM
IR/
SSA
Grammar
(with py-code)
RegExp
(more or less)
TreeGrammar
(with py-code)
Template-
Language

Mijn missie:
SoftwareBeterMaken
Grammars are (conceptually) not that hard. However:
The do depend on the tool (shown is the ANTL-grammer)
They need “extras” to become useful
Actions (code to execute when …)
• Which depend on the language to compile the grammer to
• Which depend on tool & version of the tool
ANTLR-3,4,5 supports other languages & variants
ANTRL3 supported Python2-7; now EOL. ANTLR-3 is now EOL ==> Restart?
Rewrite rules (how to build the AST)
Understand what you are parsing
• Which depend on the tool
• And the ‘mode’ your running in
Etc …
Simple in theory. Hard in practice
However: Castle will love that
Once …
Grammars (for Castle)

Mijn missie:
SoftwareBeterMaken
Expressions don’t fit nicely
Most ‘lines’ read left-to-right
LR-Grammers do match nicely
“dangling else” is exception
Easy to solve
Expressions DO NOT
Tree-order depend on operator
Recognise is easy
Parsing is NOT
Typical:
The grammer becomes clumsy

Mijn missie:
SoftwareBeterMaken
Thank You
Mijn missie:
SoftwareBeterMaken

CC-Castle; The best Real-Time/Embedded/HighTech language EVER?

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à CC-Castle; The best Real-Time/Embedded/HighTech language EVER?

Similaire à CC-Castle; The best Real-Time/Embedded/HighTech language EVER? (20)

Dernier

Dernier (20)

CC-Castle; The best Real-Time/Embedded/HighTech language EVER?