Re: STM32F4 Discovery, communication and libraries

[David Thompson <dave.thompson2@verizon.net>]

On Wed, 27 Aug 2014 09:08:07 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
<snip>
> 	Do you have any experience with assembler (any) -- since so much of C
> mapped to the PDP series instruction set (pre/post increment/decrement
> operators, for example).
> 
That's not really true -- and the related idea that these operators
are *based on* hardware is an urban legend. The PDP-11 (but not other
quite different machines in DEC's PDP "family") has post-inc and
pre-dec (not pre-inc and post-dec) for pointers that happen to be in
registers, and if you look at it slantways pre-inc and pre-dec for
8-bit or 16-bit integers. C has all 4 operations on all scalar data
types, and predecessor B had all 4 on its sole data type "word".

Ritchie's paper on C in ACM HOPL 2 used to be available on his
bell-labs page, and I saw it still there after his death, but it's
gone now and I see no archive. I feel I can quote one paragraph:

> Thompson went a step further by inventing the ++ and -- operators, 
> which increment or decrement; their prefix or postfix position 
> determines whether the alteration occurs before or after noting 
> the value of the operand. They were not in the earliest versions 
> of B, but appeared along the way. People often guess that they were 
> created to use the auto-increment and auto-decrement address modes 
> provided by the DEC PDP-11 on which C and Unix first became popular. 
> This is historically impossible, since there was no PDP-11 when B 
> was developed. The PDP-7, however, did have a few `auto-increment' 
> memory cells, with the property that an indirect memory reference 
> through them incremented the cell. This feature probably suggested 
> such operators to Thompson; the generalization to make them both 
> prefix and postfix was his own. Indeed, the auto-increment cells 
> were not used directly in implementation of the operators, and a 
> stronger motivation for the innovation was probably his observation 
> that the translation of ++x was smaller than that of x=x+1.  

A confirming post is available at http://yarchive.net/comp/c.html .

OTOH the ambiguity whether C type 'char' is signed or unsigned does
trace largely to the PDP-11 preferring sign extension (MOVB) where
other systems either don't or have an equal choice.

> 	C, itself, is a fairly small language -- it's main feature being also
> its main problem: it assumes the programmer knows what they are doing and
> offers easy access to (mis)treating data as addresses in memory.
> 
Or treating garbage as addresses. Or garbage as data.

> 	If you are familiar with Java AND with disciplined software
> development, a copy of the K&R book for C should be all you need to learn
> the language itself (in my world, it was the even smaller first edition K&R
> with my experience of FORTRAN, COBOL, Pascal, and Assembler -- circa 1982).
> 
Bearing in mind that even K&R 2ed is C89 aka C90 and there are 
two later versions of the C standard (three if you count C90 NA1).
Although if you understand K&R2 well and some language-independent
fundamentals, looking at the specific items called out as changes in
C99 and C11 may be enough. And if you don't want to pay for the actual
standards, committee drafts that are equivalent for all practical
purposes are free-beer on http://www.open-std.org/jtc1/sc22/wg14/ .

> 	C++, OTOH... THAT is a nightmare language to pick up... Do NOT think of
> it as just a more powerful C.
> 
> >So far I have investigated the following high level language alternatives:
> >
> >1. www.espruino.com (JavaScript)
> 
> 	Interpreted... And not even full Java... I've not looked at the link --
> JavaScript is the "native" language for the BeagleBone Black, as I recall.
> 
Javascript and Java are almost completely unrelated except for the
latters J a v a and a little syntax copied from C. As wikipedia
correctly says, Javascript semantics are closer to Scheme.

<snip rest>