The programming language “immediate C” or iC is a declarative, event driven extension of the procedural language C – useful for control and 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 to C programmers.
Continue reading “The computer language “immediate C””
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
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”
Fifty years ago 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 mini computer 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.
The main impetus for doing this work came from a publication by Digital Equipment Corporation – INTRODUCTION TO PROGRAMMING PDP-8 Family Computers published in 1968.
Continue reading “Real Time Operating System “OSCAR””
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> strings 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”