Missing half the skill?

[DougieLawson]

I don't know if it's a good idea for budding programmers to know an assembler.

Me neither. There are definitely things you learn with assembler that you don't learn elsewhere. That said the last time I wrote any assembler was in the 90s. For ARM under RISCOS when BBC BasicV proved too slow for the heavy lifting.

It certainly makes the post-mortem memory dumps easier when you can read the machine code and you don't get that without being an assembler programmer. The mainframe post-mortem dump analysis tool will convert machine code to assembler for you (which is useful as IBM keep extending their instruction set). I'm still writing assembler code for my day job.

If you don't do assembler you're stuck at the layer above where C is closest you'll get to the machine code.

The ARM assembler is quite elegant and has a lot of similarity to S/370. Gene Amdahl would be proud of the ARM designers.

[thagrol]

The ARM assembler is quite elegant and has a lot of similarity to S/370. Gene Amdahl would be proud of the ARM designers.

Yeah. Back then around 44 instructions each with the ability to have a conditional attached to them inside the instruction word. The alternate register sets were handy too and I always though the ability to store some constants in the unused bits of the 32 bit word was cool too.

I guess current ARM chips support that and more. I stopped after StrongARM so don't really know.

Don't know about the S/370 comparision. I never worked on mainframes.

[jahboater]

Don't know about the S/370 comparision. I never worked on mainframes.

R14 for the return address, 4 bit register fields that read easily in hex.
Aarch64 now has 5 bit register fields ........

[swampdog]

C++ is too complex and C is not taught properly.

I agree, C++ is absurdly complex. Whilst at the same time not doing anything to make programs more robust than C.

Also agree that C is a much simpler language. However using it to create robust, complex code is anything but simple.

I tend to use C++ in a C fashion. I have a C++ "void*" base class which is aesthetically nasty but functional in that it encapsulates realloc(). There's a template sdMem<> sat on top of it which I use for wrapping C calls, typically "char" but any object. I take the overhead of copying the C item into a class or std::string etc. There may be buffer overruns if I've misread the docs but there is never a memory leak.

If I'm at liberty to give one quick example it's "SDE_NULL(x)" where 'x' is a C++ pointer argument. It's a horrible macro of mine which tests for null at runtime and raises an exception.

The fact that you needed to create that macro show up a huge problem in the supposedly "high level" language.

The code goes back decades.

Code: Select all

#       define  SDE_NULL(x)     if (0==(x)) do{ \
                                        using sd::sde_Null; \
                                        throw sde_Null(SD_SFL(x)); \
                                        }while(0)
 

..more useful than "assert".

I don't know if it's a good idea for budding programmers to know an assembler.

Back in the dark ages, before any kind of home computer, we learned BASIC is school. That was a good introduction to what a program even is and what it means to program.

However, in that same year we were taught assembler and producing an assembler project contributed significantly to our final grades.

I learnt 6502 on an apple II. Well, taster. It wasn't until the BBC micro that I knew 6502 inside out. The physics master spent more than the entire budget on that apple then legged it back into industry.

BBC micro: best documentation ever!

As a result I feel that anyone who aspires to program computers should have some experience with assembler.

Pointers are not going away though. Even if it's just array element a[0] indexing a[7], still a pointer.

I'm sure pointers are not going away. But they are very different things to array indexing in a high level language.

I could write a[-1] in my K&R C compiler and it really would generate code to access a[0] - sizeof a[0] and you could write..

Code: Select all

"123"[1] = '9'

..and it would be "193" - and no memory protection!

[cleverca22]

Don't know about the S/370 comparision. I never worked on mainframes.

R14 for the return address, 4 bit register fields that read easily in hex.
Aarch64 now has 5 bit register fields ........

in both arm and vpu, things like "lr" are just aliases for specially numbered registers like that r14

and in vpu specifically, there are some thumb/arm like things, where you can either use a 32bit opcode and 5bit reg# (r0 to r31)
or you can use a 16bit opcode and 4bit reg# (r0 to r15)

unlike arm however, you can freely mix 16bit and 32bit opcodes, so the compiler can generate denser code by just prefering the lower 16 regs

[timrowledge]

but at the end of the day there's nothing better for debugging than judicious print statements.

I rather strongly disagree. A *good* debugger is hugely more powerful. A good debugger in a live-programming system is even better.

[jahboater]

unlike arm however, you can freely mix 16bit and 32bit opcodes, so the compiler can generate denser code by just prefering the lower 16 regs

Yes, I was just mentioning a couple of obvious similarities between 32-bit ARM and the S/370 mainframe.
In 32-bit ARM mode you can mix 16-bit and 32-bit opcodes, its called T32 or thumb-2.
Works well, I see about 25% reduction in code size with no loss of speed (just add -mthumb to the compiler options).

[cleverca22]

but at the end of the day there's nothing better for debugging than judicious print statements.

I rather strongly disagree. A *good* debugger is hugely more powerful. A good debugger in a live-programming system is even better.

and half the stuff ive been working on is on the VPU, and broadcom wont release documentation on how to use its jtag port
so i'm stuck debugging exclusively with print statements, until i create my own gdbstub from scratch and add gdb support for that target, lol

and yeah, arm-jtag has solved a number of tricky problems that printing couldnt, such as booting an arm32 baremetal kernel in arm64 mode, so nothing worked at all, not even printing!

[Heater]

I could write a[-1] in my K&R C compiler and it really would generate code to access a[0] - sizeof a[0] and you could write..

I have no doubt that is true. I recall the days when a C compiler seemed to compile pretty much anything. Whether that program actually worked as one expected was another matter.

However, in the C programming language as defined by the ISO standard, since forever, ISO/IEC 9899 (in it's various versions), accessing an array outside of it's bounds has "undefined behavior".
See: http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf

So, if you have been writing code that depends on such "undefined" behavior it is not C and not guaranteed to work correctly with any standards conformant compiler.

[swampdog]

at the end of the day there's nothing better for debugging than judicious print statements. That gets tedious real quick which instils defensive programming.

Absolutely agree though as I'm mostly writing python these days I tend to use the logging module.

I don't know if it's a good idea for budding programmers to know an assembler.

Me neither. There are definitely things you learn with assembler that you don't learn elsewhere. That said the last time I wrote any assembler was in the 90s. For ARM under RISCOS when BBC BasicV proved too slow for the heavy lifting.

I wrote a 6502 disassembler for my A level project on a beeb but there was a problem. It comes back to your initial post and my answer of "do". There were four BBC's. Two had tapes. Two had floppies. Some muppet discovered a call to load/unload the disc drive head, thought it sounded nice so wrote a basic program to make a couple of FX calls to load/unload the head to make buzzy music. Dead drives.

Consequently, everyone got banned off the beebs & I had to write all the code by hand. I mean on paper using a datasheet. I'd got special dispensation to use the beeb in the first place. We were supposed to use the vax. It took a while for the datasheet to turn up. Meantime I'd confused the 6502 zero,X and zero,Y indexing. Buried in my A level code is Z,X -> Z,Y emulation (or vice versa, I forget).

I did get use of a beeb about 6 weeks before hand in date but I've already been too verbose this night.

Love the seal centre story BTW.

I think these are the links..
Mablethorpe, Lincolnshire. https://www.thesealsanctuary.co.uk/
I'm informed the parrot sanctuary near Boston http://www.lincswildlife.com/plan-your- ... inding-us/ has been infected by swearing african greys.

[swampdog]

I don't know if it's a good idea for budding programmers to know an assembler.

Me neither. There are definitely things you learn with assembler that you don't learn elsewhere. That said the last time I wrote any assembler was in the 90s. For ARM under RISCOS when BBC BasicV proved too slow for the heavy lifting.

It certainly makes the post-mortem memory dumps easier when you can read the machine code and you don't get that without being an assembler programmer. The mainframe post-mortem dump analysis tool will convert machine code to assembler for you (which is useful as IBM keep extending their instruction set). I'm still writing assembler code for my day job.

If you don't do assembler you're stuck at the layer above where C is closest you'll get to the machine code.

The ARM assembler is quite elegant and has a lot of similarity to S/370. Gene Amdahl would be proud of the ARM designers.

My gut feeling is they should know asm but like every other tech that evolves, there's specialisation. My stepson does something I could never do - web programming which imo is the antipathes of programming & specialisation. We've a silent agreement not to discuss tech.

[swampdog]

The quoting was getting complex. I hope I haven't over-snipped.

I'm sure pointers are not going away. But they are very different things to array indexing in a high level language.

Well you say that. C++ has smart pointers, iterators etc, which are defined in terms of pointers which are themselves not completely defined. I agree with you. Pointers are indirection, like me going to bob's house and being told he's somewhere else. If I ask wendy to park behind my car she is at car[-1], I'm at car[0] and the school chelsea tractor blocking me, is at car[1] in front.

I think I may have just had an epiphany there on how to explain stuff to noobs. I'll guarantee you I'll have forgotten what I said within the hour (imsomnia).

[hippy]

A thing beginners also always do is execute everything with "sudo". Executing ANYTHING with full unix super user permissions is extremely dangerous on any UNIX system. (Including the Raspberry Pi)

The trouble is that, when you have to use sudo to run raspi-config to alter something trivial, update or upgrade the system, reboot or shutdown, or edit any of the system files to configure networking and so on, it's easy to take sudo as a substitute for "please" and that habit easily sticks.

There are also issues caused by not using sudo; don't do a 'sudo pip' and your Python programs won't run when you try to run those at boot-up because the libraries probably won't be where they are needed.

Most Pi users don't care or aren't aware of what damage sudo may allow only that they need to use it do what they want to do; if it doesn't work put sudo in front of it.

I have previously said that I don't think permissions are fine grained enough for the typical Pi user who is also a system administrator of their own machine and my view hasn't changed.

[Imperf3kt]

And I added that the best approach IMO is to give them the answer they immediately want and how to find the answers for themselves in future.

I know you did and to a limited extent I agree (as wintnessed by the portion of my post you didn't quote).

I've taken that approach in the past and will likely do so again. My concern is that once they've got the answer they won't read further, won't follow any links, and likely won't make the connection next time they hit a problem they don't know the answer to. That rather than apply the advice given (read the man page, read the docs, search the forum, search the web) they'll just be back asking for another tin of sardines.

Then that's when you, beginning to notice this behaviour, simply point to the documentation you already linked and re-quote yourself.
Hopefully nobody else chimes in with the can of sardines, and the poster is left with no alternative but to actually follow your advice (or go elsewhere to be spoon-fed)

This will naturally separate those who are lazy and cannot be bothered learning, from those who are eager and will go far.

So, as I posted before, this: viewtopic.php?f=31&t=288166#p1741724

[Heater]

Well you say that.

Yes I say that.

Of course it all depends on what language you are talking about and how it defines pointers and arrays.

In C and C++ there is of course a very tight relationship between raw pointers and arrays and array elements.

That need on be so. For example:

I can imagine a language where A is an array and A[42] is an element of that array.

In my imaginary language I could allow that P is a pointer to that element. Perhaps created from P = &A[42]. One could use it to refer to that element, pass it to functions and threads and so on so that they can refer to that same element.

BUT, that does not imply that P + 1 is necessarily a pointer to the next element of the array A[43].

Why should it?

Perhaps I do not store arrays in such simple consecutive order in memory in my imaginary language.

What I'm getting at is that a low level concept like a memory address, a pointer, need not have any relation to a high level language concept like an array.

In fact, I don't need to imagine such a language. In the Rust language there are no pointers in normal use. In not so normal use, denoted with the "unsafe" keyword, you can get raw pointers to values and objects and array elements. But ideas like P + 1 are undefined behavior.

[swampdog]

but at the end of the day there's nothing better for debugging than judicious print statements.

I rather strongly disagree. A *good* debugger is hugely more powerful. A good debugger in a live-programming system is even better.

In industry, you get a vague report. You can't attach a debugger, good or bad, to (say) a secured banking app.

I've been around since gcc 2.95 and I know little more on the gdb command line than how to invoke a backtrace. Certainly. If the code is in front of me, I can fire up a GUI and have it step/break (ie control gdb for me) but it is largely pointless. The code should have been unit tested.

Bear in mind also, there are unix variants that are military grade (eg: AIX). Loosely that means once that mode is enabled you ain't debugging squat (you can't change the OS) and the missile you just launched had better go down that chimney else if it has fuel and loses target, it may just lock onto your own exhaust.

Unit testing

[swampdog]

I could write a[-1] in my K&R C compiler and it really would generate code to access a[0] - sizeof a[0] and you could write..

I have no doubt that is true. I recall the days when a C compiler seemed to compile pretty much anything. Whether that program actually worked as one expected was another matter.

However, in the C programming language as defined by the ISO standard, since forever, ISO/IEC 9899 (in it's various versions), accessing an array outside of it's bounds has "undefined behavior".
See: http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf

So, if you have been writing code that depends on such "undefined" behavior it is not C and not guaranteed to work correctly with any standards conformant compiler.

No need to panic. I think you missed it was K&R days. My first cross platform program was a pig. My compiler was K&R and it was early ansi days so no standard. 16bit int on my compiler. 32bit int on another. Big endian/little endian and once you've got that sorted, problems with malloc() and stack frames because the ibm pc was pant's back then with it's 640k and "modes".

[cleverca22]

viewtopic.php?p=1742206#p1742206

this thread reminded me of something i did many many years ago when somebody was asking for help with a problem
it happened to also be a problem i wanted solved, and instead of just writing the code for the guy and solving both of our problems, i just helped to find examples, and debug it a bit, then took a copy of it to base my own work on

though in this case, one of my many side-projects needs to parse edid, so generating a fake edid file isnt of much direct use, but it is pushing me towards reading docs i wanted to read anyways! heh

[swampdog]

Well you say that.

Yes I say that.

Of course it all depends on what language you are talking about and how it defines pointers and arrays.

In C and C++ there is of course a very tight relationship between raw pointers and arrays and array elements.

That need on be so. For example:

I can imagine a language where A is an array and A[42] is an element of that array.

In my imaginary language I could allow that P is a pointer to that element. Perhaps created from P = &A[42]. One could use it to refer to that element, pass it to functions and threads and so on so that they can refer to that same element.

BUT, that does not imply that P + 1 is necessarily a pointer to the next element of the array A[43].

Why should it?

Perhaps I do not store arrays in such simple consecutive order in memory in my imaginary language.

What I'm getting at is that a low level concept like a memory address, a pointer, need not have any relation to a high level language concept like an array.

In fact, I don't need to imagine such a language. In the Rust language there are no pointers in normal use. In not so normal use, denoted with the "unsafe" keyword, you can get raw pointers to values and objects and array elements. But ideas like P + 1 are undefined behavior.

In any sane language P+1 is a[43]. That's why C++ has iterators such that it can be abstracted away. The difference between the guarantees of vector<> and deque<> perhaps? Using either type with an index is (or iterator) functionally the same so I'm not seeing your point. I can take the address of a vector<> element plus a range and know they are in consecutive memory.

In order to define consecutive memory one needs to define a base address plus a length. Someone is going to ask what a base address is.

[thagrol]

Then that's when you, beginning to notice this behaviour, simply point to the documentation you already linked and re-quote yourself.
Hopefully nobody else chimes in with the can of sardines, and the poster is left with no alternative but to actually follow your advice (or go elsewhere to be spoon-fed)

This will naturally separate those who are lazy and cannot be bothered learning, from those who are eager and will go far.

So, as I posted before, this: viewtopic.php?f=31&t=288166#p1741724

Been there, done that.

If I'm in a particularly grumpy mood I'll use the politician's answer: "I refer the honourable gentleman to my previous answer" instead of the forum poster one: "Try searching ym previous posts".

[thagrol]

The code should have been unit tested.

And that leads me to something else that doesn't appear to get taught: testing, test case design and writing good bug reports.

Taking the brief I posited in this thread viewtopic.php?f=31&t=288248 here's how things often go:

The programmer's test cases:
Data set: 2, 2, 2, 2 *
Expected result: 2

The novice tester's test cases:
The above plus

Data set: 1, 2, 3, 4 *
Expected result: 2.5

The experienced tester's test case
The above plus

Data set: 2 *
Expected result: 2

Data set: *
Expected result: suitable message not a divide by zero error

Data set: 1.5, 0.1, 99999999999999999999 *
Expected result:

Then the more devious stuff intended to break the code.

Or to put it another way:
The programmer tests that it works under ideal and limited conditions.
The novice tester tests that it works under ideal conditions.
The experienced tester emphasizes edge and corner cases.
The true tester does all the above and actively tries to break the code.

Edit: Regarding writing good bug reports. Make 'em repeatable and make 'em detailed (attached logs and/or screen shots; provide step by step instructions; etc.) Though I did once get away with a two word bug report of "loader doesn't"

[Imperf3kt]

^ the True tester is likely being paid a salary and not a hobbyist fiddling with a non-critical system.

That isn't to say don't do it (I always try to break my code so I can find exploits or bugs) just that it's a luxury not everyone has or needs.

[Heater]

No need to panic. I think you missed it was K&R days. My first cross platform program was a pig. My compiler was K&R and it was early ansi days so no standard. 16bit int on my compiler. 32bit int on another. Big endian/little endian and once you've got that sorted, problems with malloc() and stack frames because the ibm pc was pant's back then with it's 640k and "modes".

No panic. Sounds like we have trodden similar ground. You bringing fond memories (painful memories) to mind. I took the approach of insisting that all the C/C++ code our team produced had to build, run and be tested on Linux, Windows and Mac, as well a the Motorola 68000, PowerPC and ARM architectures our target systems were built with. It's amazing what bugs you find when using so many different compilers and processors.

[Heater]

In any sane language P+1 is a[43].

That is a rather narrow definition of "sane". Many would disagree.

They would argue that a vector/array is a high level, abstract, construct in a programming language. How it is actually implemented under the hood should be of no consequence to people writing code in the language. That leaves open the possibility that the actual data of the vector/array is not actually stored as consecutive memory locations. Poking around at the internals of the vector/array with a pointer to memory breaks that abstraction and is not appropriate in a high level language.

Even the C language maintains such abstraction in many places. For example picking out the bits and bytes of floats and doubles results in undefined behavior. C does not define the storage layout of those.

Heck as far as I recall picking out the bytes of integer types from their memory addresses is undefined behavior. C does not specify the order of those bytes in memory or even what format they are stored in.

Looked at that way, the fact that you can peek and poke into an array/vector in C/C++ with a pointer is rather an odd case in the language.

[jahboater]

Looked at that way, the fact that you can peek and poke into an array/vector in C/C++ with a pointer is rather an odd case in the language.

But extremely common in general.
So common in fact that processors have explicit hardware for dealing with it.
And ARM, aarch64, and even the PDP 11, implement "n = *ptr++" in a single instruction.
If efficiency is a concern, any sane language would exploit this.