[C] Pointers - what is the point?

[brucehoult]

Assembly? No no no, poor Simon, jeez, C is all you need to learn about pointers!

http://publications.gbdirect.co.uk/c_book/chapter5/pointers.html

Call me thick, but 40 years ago when I was learning this stuff, I didn't understand it until I understood the machine code.

I always suspect that people who don't do it that way don't actually understand as well as they think they do!

[hamster_nz]

Assembly? No no no, poor Simon, jeez, C is all you need to learn about pointers!

http://publications.gbdirect.co.uk/c_book/chapter5/pointers.html

Call me thick, but 40 years ago when I was learning this stuff, I didn't understand it until I understood the machine code.

I always suspect that people who don't do it that way don't actually understand as well as they think they do!

Agreed - when you understand the lower layers under C machine code then lots of the of seeming arbitrary exceptions and gotchas and become understandable and obvious. Otherwises it is a bit like learning maths by rote.

<rant>
One thing I never got a good hand on was the number of days in a month.

That stupid rhyme where you can swap months around at random, why 28, 30, 31 days?

If I lost a few fingers to count on I would be stuffed.

At least leap days make sense, as it is a crude form of Digital Differential Analyzer...
</rant>

[westfw]

Quote

These days I'd recommend using one of the following

TI's MSP430 is about as close to a PDP-11 as you can get for less than $1, and I think it still qualifies as a "current" architecture.It looks like assembly would be pretty nice on it (and potentially useful, since they sell some Very Tiny (512B) chips), and you can get those LaunchPad boards for under $15, some with FRAM (which is also "interesting technology")
http://www.oocities.org/westfw/trip-report-msp430.txt (quite old; predates cheap, predates launchpad, predates FRAM)

[brucehoult]

Quote

These days I'd recommend using one of the following

TI's MSP430 is about as close to a PDP-11 as you can get for less than $1, and I think it still qualifies as a "current" architecture.It looks like assembly would be pretty nice on it (and potentially useful, since they sell some Very Tiny (512B) chips), and you can get those LaunchPad boards for under $15, some with FRAM (which is also "interesting technology")
http://www.oocities.org/westfw/trip-report-msp430.txt (quite old; predates cheap, predates launchpad, predates FRAM)

It's definitely decent. Twice the registers of the PDP11 (which was always a bit short), in exchange for  half the addressing modes. It's a bit annoying that the destination can only use half the addressing modes that you *do* have -- and in particular that you can't do register indirect for the destination but have to waste a word on a zero offset.

Super-H (especially SH4) is similarly PDP11-ish, but getting to 16 registers by keeping a full set of addressing modes, but using them only for (one operand of) MOV. All the arithmetic is register-to-register, RISC style. I think I find this preferable.

Both MSP430 and SH4 would be vastly better for learning assembly language than any 8 bit CPU (except AVR), anything ever designed by Intel, Thumb2 or Aarch64, SPARC, PowerPC. Many of those are fine CPUs and no problem at all if you've got a compiler to do the work. But manuals thousands of pages long are not good for assembly langauge programming, especially by beginners.

I shouldn't omit m68000 (forget the 020/040 additions). Also PDP11-ish, but this time getting 16 registers by specialising them into use as pointers or for arithmetic.

With that bit of sometime annoying asymmetry I think I'd put 68k on the same level as MSP430, and SH4 just above both. All are preferable to PDP11 or Thumb1 which are just a little bit too tight on usable registers (but at least Thumb gets PC, SP, LR out of the working registers).

There's quite a lot of good choices really :-)

[brucehoult]

<rant>
One thing I never got a good hand on was the number of days in a month.

That stupid rhyme where you can swap months around at random, why 28, 30, 31 days?
</rant>

Never had too much trouble with that. In the first seven months of the year odd number months have 31 days. In the last five months it's the even months that have 31. All the rest have 30, except February.

days = m&1 ^ m>7 ? 31 : m!=2 ? 30 : 28+leapShit(yr)

[JPortici]

Agreed - when you understand the lower layers under C machine code then lots of the of seeming arbitrary exceptions and gotchas and become understandable and obvious. Otherwises it is a bit like learning maths by rote.

Expecially obvious. Many of the things i see being repeated ad nauseam about pointers, safety and how to write better or more efficient C in general became obvious once i learned one instruction set that supported indirect addressing, which in my case was dsPIC. DLX came into my life some years later, i was doing dsPICs in high scool..

[GeorgeOfTheJungle]

That's all well and it's a Good Thing (TM): the more you know your CPU the better.

That said, IMO you don't need to know assembly, an ISA, and its addressing modes, to fully understand and be able to use pointers (and handles) in C, properly.

I beg to differ. Cordially 

[newbrain]

<rant>
One thing I never got a good hand on was the number of days in a month.

That stupid rhyme where you can swap months around at random, why 28, 30, 31 days?
</rant>

Never had too much trouble with that. In the first seven months of the year odd number months have 31 days. In the last five months it's the even months that have 31. All the rest have 30, except February.

days = m&1 ^ m>7 ? 31 : m!=2 ? 30 : 28+leapShit(yr)

Ah, those pesky Roman emperors, not only they wanted months with their name, they had to be 31 days long!

[tggzzz]

One thing I never got a good hand on was the number of days in a month.

That's easy and predictable - unlike seconds in a minute, hours in a day, months in a year, days in a year.

[GeorgeOfTheJungle]

One thing I never got a good hand on was the number of days in a month.

Hey, google "months knuckles trick" in youtube! 

[bd139]

I have no idea. I just look at the calendar on the computer. 

[GeorgeOfTheJungle]

I ~ always have to stop and think to get left and right, right.

[NorthGuy]

Call me thick, but 40 years ago when I was learning this stuff, I didn't understand it until I understood the machine code.

I always suspect that people who don't do it that way don't actually understand as well as they think they do!

That's why they want languages without pointers.

[T3sl4co1l]

If at least X and Y had been 16 bits ...

...You'd have had a Z80. Oh, and throw in some more registers while you're at it, oh and let's fix that ratty instruction set.... ahhhh.

Still bloody slow, but not a pain to write for.

Tim

[rhb]

The classic example for pointers is:

char* strcpy( char* to, char* from){

   char* ptr;

   ptr = to;

   while( *from ){
      *ptr++ = *from++;
   }
    *ptr = 0;
   return to;
}

Most CPU instruction sets have increment and decrement instructions.

It's important to note that C was created to simplify porting Unix from the PDP-7 to the PDP-11. Unix was not written entirely in assembly even on the PDP-7, but most other operating systems were.  Under the mistaken belief it was necessary to get good performance.

[rrinker]

I still do 6502 assembly sometimes, just for fun. Not having any 16 bit register is a real PITA (*). The 65c02 was a disappointing upgrade, many mostly unneded additional opcodes that nobody wanted/asked for, and still no 16 bits nowhere.

(*) Strictly speaking it had one: the PC 

 My first machine for direct machine language programming was the CDP1802 - 16 registers of 16 bits, with NONE of those pre-assigned to any function (you could make any of them the PC, on the fly, and you could make any the pointer index, on the fly - with the best instruction mnemonic ever in a micro - SEX). Next one I learned was Z80, when my TRS-80 owning best friend bought the Editor/Assembler and had no idea what to do with it. I later had a project in school on Apple IIs, where part of my program was just way too slow in BASIC so I figured I'd redo the slow part in assembly. It was trying to get all that to work that just made me hate the architecture of the 6502, and to this day I fail to see why so many love it.

[sokoloff]

I think a somewhat more canonical form is:

char *strcpy( char* to, const char* from){
    for (char *ptr = to; *ptr++ = *from++; )
        ;

    return to;
}

[Tomorokoshi]

I shouldn't omit m68000 (forget the 020/040 additions). Also PDP11-ish, but this time getting 16 registers by specialising them into use as pointers or for arithmetic.

With that bit of sometime annoying asymmetry I think I'd put 68k on the same level as MSP430, and SH4 just above both. All are preferable to PDP11 or Thumb1 which are just a little bit too tight on usable registers (but at least Thumb gets PC, SP, LR out of the working registers).

There's quite a lot of good choices really :-)

My first assembly language was with the 8085, but compared to that the 68K was a joy to program. Clean and crisp.

It's interesting to compare the architecture of 68K to IBM 360:

https://en.wikipedia.org/wiki/IBM_System/360_architecture#Features
https://en.wikipedia.org/wiki/Motorola_68000#Architecture

[rhb]

I think a somewhat more canonical form is:

char *strcpy( char* to, const char* from){
    for (char *ptr = to; *ptr++ = *from++; )
        ;

    return to;
}

possibly, but I was trying to explain this to a novice. 

However, I do not consider it good style as you have to pay close attention to the punctuation or it will be wrong. It also leads you into an area where the standard states the behavior is undefined or implementation dependent.   The compiler will generate almost exactly the same code for both versions.  And with optimization turned on they would probably both produce the same assembly.

[sokoloff]

Agreed on the last. There is nothing implementation dependent or language undefined in my sample above. (At least none that I'm aware of, of course.)

[GeorgeOfTheJungle]

That strcpy code makes one cringe, null terminated strings being what they are, not the best idea ever.

[Siwastaja]

I think pointers start making sense by a little bit of experience - no need to try to force yourself to learn more this concept "by the book". The "a-HA" moment will come, don't worry.

I think, for me it happened hand-in-hand with learning of code reuse and structure - and functions. You'll see it when you first time need a 1000 lines of copy-pasta switch-case where you do the same trivial thing with 1000 different data. There has to be a better way... This teaches you to think about data structures as well, instead of focusing on the instruction flow too much. Another super important aspect in programming!

Before that, the pointers came by when using any library functions, but that's a special case which doesn't teach you too much, and at least I ended up just copy-pasting example code without full understanding. You'll see the point when you first time need the pointers in your own code, completely, and any alternative would be a huge pain in the ass.

[GeorgeOfTheJungle]

And what a great footgun they are You wouldn't get to see the most splendid segmentation faults without them.

[rhb]

Read  section 6.5.16.1 on the simple assignment operator, "=".  The strcpy(3c) case is probably okay, but a minor variation of that style can result in trouble. The root cause is the type promotion rules.

I can't imagine why anyone would object to null terminated strings.  It's far less painful than enumerated strings which is the only other choice.  I've had to mix C & FORTRAN code, a *lot* of it.  Passing strings between the two languages is a huge headache.  And long strings in FORTRAN can become far too "interesting" for my tastes.

[westfw]

I shouldn't omit m68000

I left it out on purpose.  It's a fine architecture for learning assembly language, and there are even some reasonably priced "microcontroller-style" ("Coldfire") variants, but it's pretty much drifted off out of mainstream use and into a niche that isn't much used by beginners and hobbyists.  (Much as a Coldfire-based Arduino might be "neat", I can't quite justify putting in the effort to make it happen.)
How is x86 for assembly language programming these days?  Obviously all the bells and whistles of a full-blown GUI OS desktop system are a very deep end to jump in at, but that doesn't mean you can't "learn assembly language" using a subset in a CLI or debugging environment.  I'd just be a little worried that it TOO "CISC-y" (though it need not be taught that way, I guess.)(Alas, this is the crux of the matter.  Platforms for TEACHING assembly language, vs teaching an assembly language that is actually useful...)