Apologies where they are due

I have to agree with you. I looked at C++ and the supposed efficiencies and safeguards of object orientation and decided than all the good things about it could be achieved by coding C in separate object FILES with limited public entry points and private (static) data spaces and subroutines.

And all the bad things avoided as well. Like operator overloading.

It's the same with web sites. They too now use bloated 'frameworks' designed to let people who can't code screw up in yet more novel ways.

--
"And if the blind lead the blind, both shall fall into the ditch". 

Gospel of St. Mathew 15:14

really!

surely if in a conditional statment its just a reversal of the condition..I suppose you mean assignment like "a=!a" ...

I didnt realise ARM has no div instruction

Thats the same in any language tho. Initialisation of large static objects is not done at run time in any compiled language is it?

And I cant see how you can initialise something like a dynamic array of structures in any other way than explicitly via a loop, or explicit statements..

Again that doesn't make sense. You can still map to assembler direct: the questions is WHAT assembler you map to...and what it does.

I.e. deferencing a null pointer maps straight to assembler allright, but what happens is what is undefined - seg fault, random number or whatever happens to be a memory location zero..

--
If I had all the money I've spent on drink... 
..I'd spend it on drink. 

Sir Henry (at Rawlinson's End)

Yes, or a function that just wraps it. Not always very useful but it illustrates that even conceptually simple operators don?t directly reflect single assembler instructions.

CVE-2009-1897 is a famous example. A comparison compiled to _no_ assembler instructions, due to the context in which it appeared, thereby introducing a vulnerability. Merely re-ordering a couple of statements would have produced the ?expected? assembler, illustrating that the relationship between C and assembler is not direct but actually can be highly contextual.

--
https://www.greenend.org.uk/rjk/

For and while loops are certainly not atomic. Nor is any parameter passing function call.

But, any set of one or more assignment statements which use the same variable(s) will be modified quite significantly by an optimising C compiler.

The only language where I know your statement about highly optimised individual statements is PL/9 because, although that explicitly did not attempt to optimise sets of statements, it was almost impossible to write tighter assembler to replace individual statements. I know: I tried. But even there, not all assignment statements were atomic.

Indeed, but its never made any pretence of being a small, efficient language. I nearly fell off my chair the first time I compiled a C++ version of 'hello world' with the Borland C/C++ compiler and ended up with an 800KB executable.

Oddly enough, many versions of COBOL are quite efficient when it comes to code size. ICL 1900 COBOL was reckoned to average six machine statements per COBOL sentence and the ICL 2900 reduced that to three, but then the

2900 instruction set was (a) very complex and (b) optimised for implementing high-level languages (Algol60 and 68, COBOL, FORTRAN, etc) so that, for example "MOVE ALL SPACE TO TABLE-A." was a single machine instruction even if TABLE-A was an array of record definitions.

--
Martin    | martin at 
Gregorie  | gregorie dot org

CVE-2009-1897 appears to be 'derefencing a null pointer'..

Are we talking about the same thing? - I am genuinely interested, not trying to just argue..

I think anyone who codes should be aware of the vulnerability of a language - as I discovered in Javascript when Microsofts browser interpreted a variable as a string while mozillas did, as a number.

--
Of what good are dead warriors? ? Warriors are those who desire battle  
more than peace. Those who seek battle despite peace. Those who thump  
their spears on the ground and talk of honor. Those who leap high the  
battle dance and dream of glory ? The good of dead warriors, Mother, is  
that they are dead. 
Sheri S Tepper: The Awakeners.

Assuming that you have retained some symbol table, then at each access of a variable you pick up its name in a string, eg FirstVariable.

Then, taking addition as an example, you build up another string by concatenating the 1st access, the plus sign and the second access to give you "FirstVariable + SecondVariable" and keep building up the string in the same way until you have the complete expression.

This will still work after some optimisations, but you must no allow dead code elimination because that code might be dead because it has not yet been fully edited (in my scheme where the tokens of the source code are the executable instructions)

Same as my experience over a similar time period :-)

Indentation is determined by the program structure; not to me a problem.

I never knew of that attribution, but I've been using it for years! One of the side effects of a degree in electronics where one has to be self-inventive as opposed to a comp sci degree where you'd get taught all the attributions. eg, in PDP11 assembler re-invented the wheel and discovered later its attribution as an Iliffe Vector.

Actually straightforward, and covered in a previous post, and with the string based decompilation discussed above, is the reason for wanting the two forms ...

ADD R2,R2,R3 and ADD R2,R3,R2 so that the correct original ordering is maintained.

I agree with that, BTDTWTS !!!!!

My God! Thoght for a moment I was reading my CRAP language from 1986, but the derivation from FORTH is instantly recognisable!

Knew of it: never read it. The "68 Microjournal" was my source of most knowledge back in the day when I was running FLEX09 on a 6809-based system.

The best sources I know for that are:

- "The C Programming Language" (K&R ed 2) plus "The Practice of Programming" Kernighan & Pike for somebody starting to program

- "Software Tools in Pascal" and "Algorithms" (Sedgewick) as general algorithmic handbooks

- "UNIX System Programming for SVr4" (O'Reilly books) as the best reference for the standard C POSIX library I know

- "Design of Man-Computer Dialogs" (James Martin) for guidance in implementing usable interactive systems

- "An Introduction to Database Systems" (Chris Date) for insights into database design and implementation. He worked with Ted Codd on implementing the first relational database.

The last two are quite old, but the ideas and approaches they describe are still useful.

--
Martin    | martin at 
Gregorie  | gregorie dot org

But those are not 'single operations' anyway.

My original point is that its pretty clear that e.g. a 'for' loop consists of an initialisation, a test and an increment or similar statement, plus some loop markers.

If you count the curly braces and semi-colons thats pretty much how many assembler statements there should be :-)

I make that 4.

One statement to assign initial loop variable value, one to increment it, one to compare it and one to do a conditional jump.

They will be if you are using such. Howver te oroginal ppoint is anbout a language, not an optimising compiler as such, and my point was that C to assembler is a very straighforward mapping (before optimising compilers get ther hands on it)

I seem to remember an 8086 instruction to copy DX register number of words from the memeory space pointed to by one index register to the memory space pointed to by another...REP MOVSW???

And COBOL was invented in the days when 4K of RAM was a LOT of ferrite...

I just looked at a handful of short utility programs I have written to gather data off the internet and so on

14k-20k is the average length..BUT of course these days one has dynamically loaded libraries to interface to MYSQL, CURL and the like...:-)

the ones that include statically linked libraries written in c++ are 500k...

--
"If you don?t read the news paper, you are un-informed. If you read the  
news paper, you are mis-informed." 

Mark Twain

Apart from bloat and over complex syntax, the thing I dislike most about C++ is that such a lot of the code I've seen has been effectively just ANSI C with // comments.

If you want to learn OO programming I think Java is the way to go. Yes, I know it disallows multiple inheritance, polymorphism and a few other things, but has the big advantage that since you MUST use classes and inheritance because there's no other way to write a Java Program, you will learn the elements of OO programming quite fast and without picking up many bad habits.

Most of the other OO-capable languages (C++, Perl, Python) allow you to get into bad habits like writing a horrible mishmash of OO and procedural code, often all in the same source file.

--
Martin    | martin at 
Gregorie  | gregorie dot org

"How to solve it by computer" by Dromey

Again, oldish, but got a copy recently through Abebooks.com

Of course - look at the Xt library for an example of OO in C. C++ is a horrible implementation of OO.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/

The outcome is a null pointer dereference, which an attacker can leverage to execute arbitrary code with kernel privilege. That much is not exceptional. The interesting bit (in the context of this thread) is that in the source code _there is a check for a null pointer_, which the compiler eliminates as a result of reasoning about the function as a whole.

Stripped down to the essentials:

$ cat t.c void abort();

int f(int *x) { if(!x) abort(); return *x; }

int g(int *x) { int y = *x; if(!x) abort(); return y; } $ gcc-7 -O2 -c t.c -o t.o && objdump -dMintel t.o

t.o: file format elf64-x86-64

Disassembly of section .text:

0000000000000000 : 0: 48 85 ff test rdi,rdi 3: 74 03 je 8 5: 8b 07 mov eax,DWORD PTR [rdi] 7: c3 ret 8: 48 83 ec 08 sub rsp,0x8 c: e8 00 00 00 00 call 11 11: 0f 1f 44 00 00 nop DWORD PTR [rax+rax*1+0x0] 16: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0] 1d: 00 00 00 0000000000000020 : 20: 8b 07 mov eax,DWORD PTR [rdi] 22: c3 ret

--
https://www.greenend.org.uk/rjk/

On a sunny day (Mon, 23 Apr 2018 12:46:05 +0100) it happened The Natural Philosopher wrote in :

When programming those little Microchip PIC microcontrollers, as I use a lot, I needed an UDP stack ethernet interface, wrote something from the spec: usa2-0.3.asm Program Memory Words Used: 3441

Been using that UDP stack for all sort of things, sensors, light control.

It all does not HAVE to be big.

On Mon, 23 Apr 2018 11:56:51 +0100, The Natural Philosopher declaimed the following:

It has them (at least ARMv8) but some of the behavior may require use of a subroutine to be rigorous.

"""

the quotient, which is rounded towards zero. The remainder may then be computed as numerator?(quotient denominator) using the MSUB instruction.

the most negative integer value representable in the selected register size, then the result will overflow the signed integer range. No indication of this overflow is produced and the result written to the destination register will be INT_MIN.

NOTE: The divide instructions do not generate a trap upon division by zero, but write zero to the destination register. """

At the very least, many higher level languages expect division by zero to raise a condition -- so a subroutine would likely be used incorporating the needed testing and flag setting rather than emitting the same common code every time a divide was done.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Thats not the same: what you're describing is essentially doing the same job as memcpy() does in C while COBOL's "MOVE ALL SPACE" is a special form of MOVE that overwrites an arbitrarily large memory structure with a repeated space character. I used SPACE on this case but to could equally have been amother literal constant, e.g ZERO, or a specified character value such as "A" or "7". The 2900 compiler's translation of this statement was a single instruction that took two operands: a byte value and an array pointer. More than that I can't say since nobody except engineers and compiler writers knew the machine code: the systems programming language was a bastard version of Algol68.

Quite so, but programs of up to 10,000 - 12,000 lines were not uncommon. Yes, I know that the data division took up an inordinate amount of the source file by the time a record had been declared in the input file, output file, working storage and probably in modified form as a print line as well, but even so the compilers back in the day must have been pretty good at generating compact code.

.. and 1900 COBOL was all statically linked, though the ability to divide a program into overlay segments and have them overwrite each other in memory as the program required them helped a lot.

Also, don't forget that there's a fair amount of 'hidden' code in a COBOL program - by that I mean the way COBOL used 'edited variables', e.g.

where most other languages would call field formatting functions.

--
Martin    | martin at 
Gregorie  | gregorie dot org

They were covered too, when they appeared, as well as the 88000 RISC chips.

Once you'd learnt to program from K&R, this provided help on writing readable, maintainable programs and coding styles that made debugging easier too (top-down programming rather than bottom-up, and testing as you write rather than saving all testing to the end.

... its still alive and well as Object Pascal, usually in conjunction with the Delphi IDE. I've never used it - just know its still around.

... and several books use it to present algorithms (the eponymous "Software Tools In Pascal" and Sedgwick's "Algorithms". Its a good way to describe algorithms: you can transcribe direct from the page into C on a terminal and the result tends to run as soon as you've corrected any typos. Been there, done that a few times.

--
Martin    | martin at 
Gregorie  | gregorie dot org

For a job yes - to learn what OO is all about learn Smalltalk.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

ymmv, but I find Java preferable to C for bigger, more complex programs, especially if they involve databases or GUI interfaces. Swing suits me fine, especially since I found the third party RiverLayout layout manager, as does JDBC and the various E-mail handling packages. No, this is not work-related stuff I'm talking about.

Smalltalk looks moderately interesting, though as I prefer strongly typed languages to dynamically types ones and Java is a Smalltalk derivative, I think I'm happy to stick with it.

--
Martin    | martin at 
Gregorie  | gregorie dot org

On Mon, 23 Apr 2018 13:56:01 GMT, Jan Panteltje declaimed the following:

How modern

I still have an Intel kit containing:

8080A processor 2102 RAM (8x) 1702 UV EPROM (4x) 8212 buffer/latch (3x) {meant to be used to capture shared address/data lines, as part of the bus control} 8224 Clock generator 8205 1-of-8 decoder (meant to be used for chip selects)

which I supplemented with

8228 system controller chip (replaces the three 8212s) 2708 UV EPROM 2114 RAM? (2x)

Along with an S-100 format wire-wrap board.

The most popular Pascal, in the day, was the UCSD P-code system, which unfortunately was saddled by a weird OS (could only have one file open for output per drive, as the system allocated the largest contiguous block to the file, and required periodic "packing" to consolidate free space). (I had Alcor Pascal on TRS-80/TRSDOS, which was also a p-code system, but on a much friendlier OS -- object files were text; one could actually open p-code files and hand-link functions from one program into another by cut&paste of the text).

Pascal, as originally defined, had a few problems (ignoring the ; separator vs terminator and the need for begin/end blocks). Primary is that it did not support "include" and separate compilation/linking... Everything had to be within a single source file.

C seems to have superseded the use of Pascal in colleges -- especially as UNIX sources were studied for OS classes.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/