Is C a 'good' programming language?

[DimPrawn]

Good luck Churchy. Sounds right up your street, all bits and bytes, peeking and poking. Have a nice nybble.

[VectraMan]

Interesting thread. Embedded systems programming has been mentioned a few times and I'll chime in and agree that C definitely has its place in this field. My background is electronics hardware and from that I moved into using assembler and C for PICs and ARM processors. I suppose on limited embedded platforms like these, "assembler with tits on" is exactly what you want from a programming language, and nothing more! I'm used to the concept of managing memory resources yourself and selecting the libraries to match the processor variant and peripherals you're using. I enjoy using C, and don't believe that lack of OOP features make it 'bad'.

That does suggest that it's the sort of people that do it that lead to C, i.e. coming from electronics and learning to do a bit of coding.

I've never done embedded stuff myself, but I've worked with people that do (I've done a couple of gigs writing PC software that connects to and controls hardware running embedded software). I wouldn't say they're lesser programmers, but perhaps they're "differently abled", and they don't get "software engineering". In one case I found out that the embedded team didn't use source control. They had vaguely heard of source control, but didn't see the point because it didn't acheive anything that you couldn't do with zip and emailing each other changes.

[Churchill]

That does suggest that it's the sort of people that do it that lead to C, i.e. coming from electronics and learning to do a bit of coding.

I've never done embedded stuff myself, but I've worked with people that do (I've done a couple of gigs writing PC software that connects to and controls hardware running embedded software). I wouldn't say they're lesser programmers, but perhaps they're "differently abled", and they don't get "software engineering". In one case I found out that the embedded team didn't use source control. They had vaguely heard of source control, but didn't see the point because it didn't acheive anything that you couldn't do with zip and emailing each other changes.

Hmmm, interesting point of view.

Good luck Churchy. Sounds right up your street, all bits and bytes, peeking and poking. Have a nice nybble.

Cheers DP! It's a Technical Manager role but I'll still be able to get my hands dirty!

[Churchill]

That works for me... it used to be frisbynet...

And it pays to remove the listing files from the zip before sending stuff from Norway over a 14.4k dialup line in 1996...

With "sneakernet" when you fail to catch the disk...

[RichardCranium]

Or rs232net to connect all those disparate mini, micro & bluebox mdsII systems together...

It seemed moderately complex at the time.

Along with reading 8" floppy diskettes in an interesting variety of formats...

Dear dead days really beyond recall...

Not quite. The RS242 DMS HiNet is still burned into my memory.

[d000hg]

Get the address of the display buffer/port address of the display hardware and write the data there yourself.

Not that difficult in a text-mode display. No idea about embedded devices but back in my days of MS-Dos coding in C, I remember Bios functionality to interact with files, display, etc. Didn't you fire interrupts to access this functionality? Been a while...

[Sysman]

However, including printf is usually fatal, immediately using all the code space for the library support...

Which brings back bad memories of FORTRAN programs littered with unnecessary formatting statements. Trust me, you can test for '9' in column 1 without converting it to an INTEGER first. What Churchy said for outputs.

[VectraMan]

Not that difficult in a text-mode display. No idea about embedded devices but back in my days of MS-Dos coding in C, I remember Bios functionality to interact with files, display, etc. Didn't you fire interrupts to access this functionality? Been a while...

Load ax with a command code and issue an interrupt 21h? Was that DOS? I forget.

First place I worked had a DOS based multimedia system that did direct access to the screen buffer, but for SVGA modes you had to page it into a 64K window, and the paging method was different for different graphics cards. You can still do the same in Windows with DirectX, although Aero has spasms when you do. Using a text mode display and having the system form the characters for you is cheating.

[d000hg]

Load ax with a command code and issue an interrupt 21h? Was that DOS? I forget.

IIRC there was 21h for DOS interrupts, and you could also access BIOS functions directly using another interrupt. I had a giant book detailing all the interrupts, I found it in my early teens in a shelf of books my dad had when he was a programmer years before. I also found a copy of Microsoft C 5.0 which was what I learned C on.

First place I worked had a DOS based multimedia system that did direct access to the screen buffer, but for SVGA modes you had to page it into a 64K window, and the paging method was different for different graphics cards. You can still do the same in Windows with DirectX, although Aero has spasms when you do. Using a text mode display and having the system form the characters for you is cheating.

I remember all that stuff, great fun. The hard part was accessing 16-color modes where you had to pick which color 'plane' you wanted to access on top of everything else.

I remember when I first learned how to use VESA to access the whole video buffer as a linear memory region... it was amazing!

[VectraMan]

I remember all that stuff, great fun. The hard part was accessing 16-color modes where you had to pick which color 'plane' you wanted to access on top of everything else.!

All this I did was 256 colour mode - i.e. 8bpp and a palette. We spent ages working on algorithms to try to pick the optimium palette and dithering algorithms in order to make photos look as good as possible when reduced to 256 colours. All seems a bit crazy these days where nobody would dream of having anything other than a 24bpp display.

I had the book by the bloke who wrote Doom, that went into insane detail in how to squeeze every possible bit of performance out of VGA and the x86, and I remember that talking about planes. Chock full of assember. I wish I still had it - I guess it was the company's.

Whilst we're doing memory lane (and slightly on topic), I used to do a lot of assembler for the simple reason that in 16-bit Windows in C you could only access 64K blocks of contiguous memory (unless you used huge pointers which had an unacceptable overhead), whereas assembler let you use a 32-bit offset. Assembler really was better than C in that respect.