C in a uC... what were they thinking??

[BigEd]

It's interesting that several of us - perhaps all of us - seem to find some languages inherently more comfortable than others, and find some other languages just hit a sort of mental block.

Brad isn't alone in finding C difficult, and sark02 has good company in never having gained proficiency in Forth. And we've noted that the great majority of programmers haven't even tried assembly language. APL is interesting in that there's anecdotal evidence that it's very accessible to untrained people but very difficult for people already skilled in conventional languages.

I like the idea of a language's expressiveness, and I like the idea that if you can do a job in fewer lines of code then you'll probably on average have fewer bugs. But it's clear that some languages have more overhead than others, so on tiny machines those languages can be a poor fit.

[resman]

sark02 wrote:

resman wrote:

However, I have seen engineers get carried away with the concept of building a grand "Master Control Program" (seriously, that's what one lead engineer called it) [...]

I was one of the leads on an embedded system whose main management process I named "MCP" after the Tron "Master Control Program" (and my username, "Sark" is also from Tron). Don't be hatin'.

Probably the most over-used process name in computer engineering.

[sark02]

BigEd wrote:

I like the idea of a language's expressiveness, and I like the idea that if you can do a job in fewer lines of code then you'll probably on average have fewer bugs. But it's clear that some languages have more overhead than others, so on tiny machines those languages can be a poor fit.

Where I work the Go language is becoming quite popular for systems programming (this is on x86 and ARM64). When a compiled helloworld.go is 1.6MB, the corner of my eye starts to twitch. I haven't gotten into it yet, but it looks like a fine language. Not for a small microcontroller, me thinks...

[sark02]

resman wrote:

sark02 wrote:

resman wrote:

However, I have seen engineers get carried away with the concept of building a grand "Master Control Program" (seriously, that's what one lead engineer called it) [...]

I was one of the leads on an embedded system whose main management process I named "MCP" after the Tron "Master Control Program" (and my username, "Sark" is also from Tron). Don't be hatin'.

Probably the most over-used process name in computer engineering.

I think you're mistaken. I do believe I was the first person to ever name a process MCP, and it was a brilliant and inspired choice and not even slightly unimaginative or derivative, and it pushed the bounds for art to real life crossovers.

Doh!

[BigEd]

> helloworld in Go is 1.6MByte

That does seem large, but it cannot possibly be active code - must be libraries or methods brought in.
(A bit of info at https://blog.golang.org/go1.7-binary-size)

I'm a bit of a fan-at-a-distance of Go, but I can't say I've done anything with it. It has its flaws, and its detractors, but it has good aims and good ideas. And of the order of half a million users, apparently.

[sark02]

BigEd wrote:

> helloworld in Go is 1.6MByte

That does seem large, but it cannot possibly be active code - must be libraries or methods brought in.

Oh yes, definitely! Even hello world in 'C' pulls in some initial runtime. Go pulls in more, but that's ok for the environment it's intended for. Still, the first time you see 1.6MB it gives you pause.

[commodorejohn]

The first time you see a 1.6MB hello-world, it shouldn't give you pause.

It should send you running screaming for the hills.

[BigEd]

Expectations! I think it's all part of understanding how things work. If something surprises you, there's something going on you didn't expect. So, have a look, see what it is.

The point of a compiler is to make an executable which does what the source describes - a compiler which can swallow a million lines of code and burp out a working executable quickly isn't necessarily making the smallest possible executable, and isn't necessarily broken if it makes quite a large executable when fed a trivial source. The size of that executable doesn't necessarily bear much relation to the number of instructions it will execute or the amount of memory it will occupy - which is what really matters, in everyday computing environments.

[BigDumbDinosaur]

Elminster wrote:

Reasons for not using asm is it is I won't remember how it works in a year...

A good assembly language programmer liberally comments his or her code so he or she will remember a year or five from now "how it works." I have source code from the 1980s that I heavily commented and when I look at it after a long time of it sitting in a dusty corner of the computer I can figure out what is going by simply reading what I typed 30-odd years ago.

Quote:

I think in the 6502 world people just used to asm and forget outside most people don't know asm.

6502 systems were among the first to be available to hobbyists and in those days, lacked high level language development features. So the hobbyist either wrote his software in assembly language or he depended on others to do it, or he had a useless machine with no software.

[Elminster]

BigDumbDinosaur wrote:

Elminster wrote:

Reasons for not using asm is it is I won't remember how it works in a year...

A good assembly language programmer liberally comments his or her code so he or she will remember a year or five from now "how it works." I have source code from the 1980s that I heavily commented and when I look at it after a long time of it sitting in a dusty corner of the computer I can figure out what is going by simply reading what I typed 30-odd years ago.

I assume comments by default, would be doomed without comments.. But with ASM I find it much harder to pickup commented ASM and understand it a year later than an HHL. But other mileage may vary.

Edit: i.e. Comparing Fully commented version of C vs fully commented version of ASM to non regular ASM programmers. Looks like magic.

[Tor]

I've no problem understanding my minicomputer assembly programs / libraries that I wrote in the early eighties.. even though I hadn't looked at them for decades.
I remember sitting down and writing some assembly routines now and then, to get my energy back.. it was very relaxing.

[Elminster]

Tor wrote:

I've no problem understanding my minicomputer assembly programs / libraries that I wrote in the early eighties.. even though I hadn't looked at them for decades.
I remember sitting down and writing some assembly routines now and then, to get my energy back.. it was very relaxing.

Must just be me then, I am an anomaly. I can learn things fast, but forget them even faster! I found some Cobol codeI I wrote 20 years ago at Uni the other day, complete gibberish.

[cbmeeks]

It really depends on the project at hand.

I've been programming 6502 assembly much longer than C (or Java which is my day job).

However, I also built a AY-3-8910 music player for an Arduino using the PRE-BUILT SD libraries and the PRE-BUILT serial libraries, etc. I wrote the entire project in C very quickly. Worked great. Assembly would have provided no additional benefit for THAT project. In fact, it would have taken MUCH longer because I needed various interfaces that I would have had to write myself. I don't fancy re-inventing the wheel very often.

[dwight]

I think the problem with commenting assembly language is the thought that every line should have a comment. When doing it that way the programmer tends to fall into the trap of writing a comment that is a redundant statement of the instruction.
As an example: LDX #5 ; put 5 into X
Comments of context are usually more useful.
Many like to put all their assignments at the top of the program to be in a location for common referencing but often mixing an assignment locally, especially if it is only used in that location makes more readable code. I believe more readable code is better that comments:

Grapes equ 5
...
LDX #Grapes

As an example of good naming in the right context.
Always, a statement of what you'll be doing is important for any stretch of code.
Now if only I could convince my self, while writing code, to use the good commenting practices I preach.
Dwight

[BigDumbDinosaur]

dwight wrote:

I think the problem with commenting assembly language is the thought that every line should have a comment. When doing it that way the programmer tends to fall into the trap of writing a comment that is a redundant statement of the instruction.

An example of how I comment. This is an excerpt from the DUART driver in POC V1.1's firmware. Anything in the comments that seems redundant?

Code: Select all

;DUART TRANSMITTER IRQ PROCESSING
;
iirq0300 lda #n_nxpch-1        ;starting channel
;
;
;	channel processing loop...
;
.0000010 pha                   ;save channel index
         asl a                 ;channel pointer offset
         tax
         lda (tiaisr,x)        ;get IRQ status
         bit nxptqtab,x        ;TxD interrupting?
         beq .0000040          ;no, skip this channel
;
;
;	FIFO processing loop...
;
.0000020 lda tiagettx,x        ;CFIFO 'get' pointer
         cmp tiaputtx,x        ;CFIFO 'put' pointer
         beq .0000030          ;nothing to transmit
;
         lda (tiasr,x)         ;get channel status
         bit #nxptxdr          ;TFIFO full?
         beq .0000040          ;yes, done for now
;
         lda (tiagettx,x)      ;read CFIFO &...
         sta (tiafif,x)        ;write to TFIFO
         inc tiagettx,x        ;bump 'get' pointer &...
         bra .0000020          ;loop
;
;	...end of FIFO processing loop
;
.0000030 lda #nxpcrtxd         ;disable...
         sta (tiacr,x)         ;TxD
         lda tiatstab,x        ;tell foreground...
         tsb tiatxst           ;about it
;
.0000040 pla                   ;get channel index
         dec a                 ;all channels serviced?
         bpl .0000010          ;no
;
;	...end of channel processing loop