Featured

The computer language “immediate C”

The programming language “immediate C” or iC is a declarative, event-driven extension of the procedural language C – useful for machine control, robotics and for dealing with events generated in a GUI.

iC utilizes the syntax of C to give meaning to statements that have no semantic support in C. In addition to standard variables, which are modified by the flow of instructions, iC provides so-called ‘immediate‘ variables, whose values are updated, whenever a change of input calls for an immediate change in output. An efficient Data Flow technique implements this strategy.

iC provides programmers with built-in operators, whose function is closely modelled on integrated circuits. The name iC is a reminder of this fact. Logical AND, OR, EXCLUSIVE-OR and NOT as well as D flip-flops, SR flip-flops, shift registers and many others are implemented in such a way, that their use in iC follows the same design rules, which apply to their hardware counterparts. These rules have led to a well-developed hardware technology, whose effectiveness is demonstrated by the success of today’s complex computer hardware. Particularly the concept of clocked functions plays an important role in the language iC. It gives the same protection against timing races in iC programs, as it provides for hardware IC designs. But iC is not a hardware description language nor a simulation language – it provides the functionality and some of the speed of field-programmable gate arrays with a language, which is pre-compiled into straight C code, which is portable and produces efficient machine code.

Continue reading “The computer language “immediate C””

Super Stutter Sequences for “vim”

Since the early days of UNIX, the vi editor had commands called Stutter Sequences. Two commonly used Stutter Sequence commands are dd to delete one or more lines or yy to yank (copy) one or more lines. Repeating a letter while typing is very easy and very intuitive.

Also for many decades, vi and vim had the facility to define abbreviations with the X command :ab . Abbreviations are used in Insert mode, Replace mode and Command-line mode.  If you enter a word that is an abbreviation, it is replaced with the word or sequence of words it stands for. This can be used to save typing for often-used long words. And you can use it to generate more complex blocks of text because it is possible to switch from insert mode to command mode and back in the replacement sequence.

Another useful vim function is the X command :map . It allows defining a vi command or insert sequence for pressing any key, including function keys. A series of :map and :ab commands are usually pre-defined in the vi support file ~/.exrc as part of a Linux distribution. I have extended ~/.exrc to provide extra mappings and abbreviations making up the Super Stutter Seqences.

A simple example of an abbreviation:
:ab hh    hello

:ab"hh<Space>" is expanded to "hello<Space>"

I call abbreviations consisting mostly of three identical letters followed by a non-letter “Super Stutter Sequences“. The replacement string of the Super Stutter Sequences consists of a string of insertions and vim commands and is rather cryptic. I will only show and analyze the first one in detail:

:ab iii    if ) {^M^T///^M^D}^[%F)i
Explanatory form (output by :ab listing):
:ab iii    if ) {<CR><C-T>///<CR><C-D>}<Esc>%F)i
To enter <CR> type ctrl-V <Enter> which shows up as ^M
To enter <C-T> type ctrl-V ctrl-T which shows up as ^T
To enter <C-D> type ctrl-V ctrl-D which shows up as ^D
To enter <Esc> type ctrl-V <Esc> which shows up as ^[

The replacement string starts with “if ) {“. <CR> starts a new line. <C-T> indents text in that line by 4 spaces to the right. “///” is inserted in that line at the new indent. Another <CR> starts a third line. <C-D> indents text 4 spaces to the left, where the closing brace “}” to finish the block is inserted. The insert cursor is now after the closing brace. An <Esc> follows, which turns on command mode. The vi command “%” moves the insert cursor to the matching opening brace in the first line. The vi command “F)” moves the insert cursor in front of the “)” after the “if“, which was inserted at the beginning. The vi command “i” restores insert mode at which point the abbreviation for “iii” is complete. The abbreviation trigger character “(” is now inserted before the “)” character leaving the insert cursor in insert mode between the parentheses.

NOTE: in the following expansions the character ‘|‘ represents the insert cursor and not the vertical bar character.

"iii(" is expanded to
if (|) {
    ///
}

Continue reading “Super Stutter Sequences for “vim””

Real Time Operating System “OSCAR”

In 1969 I worked at an industrial research laboratory designing factory automation systems using mainly TTL IC hardware. I was interested in doing some of this work in software using the newly emerging mini-computers. To come up to speed I studied at night for a Masters degree in computer science at the University of NSW (UNSW) in Sydney, Australia.

As part of this course, I designed and programmed a “Real-Time Operating System” for programming Real-Time Control Systems. It was called a Monitor at the time. The first version of this program was implemented on a PDP-8 minicomputer in the Electrical Engineering department of the university. Afterwards, I ported the software to a Data General NOVA mini-computer for my then employer (which was not a good idea I discovered later). I gave the system the acronym OSCAR for Operating System CSR Automation Research.

For the 50th anniversary, I obtained a PDP-8/I kit from Oscar Vermeulen in Holland, which works beautifully. The kit has an exact facsimile of a PDP-8/I front panel with working switches and lights. In the back is a Raspberry Pi running the SIMH PDP-8 emulator software with all major PDP-8 system programs on a simulated RK05 disc. I was able to reconstitute all the OSCAR sources from printouts I have and assemble and run it all, as I did 50 years ago (see PDP-8 sources).

Continue reading “Real Time Operating System “OSCAR””

BALAD (Beginners Assembly Language and Debugger)

BALAD is an assembly-level programming language for an emulated virtual computer with a 15-bit word length. It is combined with a comprehensive debugging system that allows online program assembly, execution of programs and the insertion of breakpoints to allow suspension of programs during execution.

Instructions are machine-oriented, using integer and logical operations only. As a concession to the beginner, extra input/output instructions are provided for automatic Decimal to Binary conversion and the printing of Text Strings. These facilities will enable students to obtain a reasonable printout of their results quickly while concentrating their efforts on developing algorithms.

The following tells the story of how BALAD was first developed in the ’70s for teaching computer technicians the basic workings of a computer and my recent efforts to re-write BALAD to run on a PC. To complete the story I reach back to my first contact with the English Electric Deuce vacuum tube computer UTECOM in which I was privileged to write my first computer program in 1957. I ported the higher-level language GEORGE, used on UTECOM to BALAD to show how little computer resources are needed for a very useful program.

Continue reading “BALAD (Beginners Assembly Language and Debugger)”

GIT correct $Id keyword expansion

This blog describes a set of hooks for GIT, which do real version number incrementing when a file that contains a well-formed $Id string is committed. These hooks have absolutely no effect on files not containing a $Id string. A major feature of these hooks is the fact that they are compatible with GIT branch names and store the branch name from which a file is committed in the $Id string.

The format of a clean well-formed $Id <version> string for these hooks is very similar to those used by RCS/CVS/SVN, namely full stop separated pairs of major and minor versions:

* the first string is the major version number in the master branch.
* even strings are consecutive version numbers in the branch.
* odd strings identify branches (branch names or numbers).

The following are a sequence if $Id strings for the file xx.c after a series of 3 edit/commits in the ‘master’ branch followed by 2 edit/commits in branch ‘bxx’ followed by an edit/commit in branch ‘byy’:

$Id: xx.c 1.1 $
$Id: xx.c 1.2 $
$Id: xx.c 1.3 $
$Id: xx.c 1.3.bxx.1 $
$Id: xx.c 1.3.bxx.2 $
$Id: xx.c 1.3.bxx.2.byy.1 $

This is how the $Id text is stored in the GIT archive after each commit. After ‘smudging’, which is applied to the file in the working directory after a git commit/fetch/checkout, the last $Id would look like this:

$Id: xx.c 1.3.bxx.2.byy.1 30e82ef 2016-04-03 14:48:24 +1000 Joe Blow $

This automatic method if $Id keyword expansion shows the current file name, the branch in which an instance of a file was edited and its individual version number within that branch.  This information is embedded in the text of a file in a manner, which is fully compatible with GIT. After smudging, the $Id also shows the commit SHA-1, the date and the author of the file instance. The $Id information in each file provides an independent file oriented view, which can be regarded as a belts and braces approach to handling files in GIT.

Continue reading “GIT correct $Id keyword expansion”

The Inverse Peter Principle

This article was first published in DATAMATION, April, 1974, page 123, 125. Although this article appeared in an April issue, which traditionally contained some humorous articles, this article is very astute and critical of upper echelon management in a tongue in cheek way. My experience as a systems programmer, software engineer in factory automation, chief engineer of a computer company and finally consultant have given me much insight and I have seen many cases where the Inverse Peter Principle applies. Since I cannot find the article in the internet today, I feel its humour and wisdom should not be lost on today’s “doers”.

The Inverse Peter Principle

A. Nonymous

AFTER READING The Peter Principle and its sequel The Peter Prescription it has occurred to me that Dr. Peter, astute though he undoubtedly is, got the whole process backward when he stated that an employee starts off competent, then rises through promotion to a position where he is not competent to perform his job. I have found that more often than not, the very opposite happens: those employees who demonstrate competence in performing menial technical tasks tend to remain at the bottom performing those tasks, since it is in the company’s interest to make sure those basic functions are performed with as little fuss and retraining of newcomers as possible. Continue reading “The Inverse Peter Principle”