Page 2 of 6
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 6:17 pm
by 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.
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 6:39 pm
by resman
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.
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 6:40 pm
by sark02
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...
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 6:45 pm
by sark02
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!
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 6:49 pm
by 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.
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 7:16 pm
by sark02
> 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.
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 10:11 pm
by 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.
Re: C in a uC... what were they thinking??
Posted: Sat Jul 15, 2017 10:30 pm
by 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.
Re: C in a uC... what were they thinking??
Posted: Sun Jul 16, 2017 4:55 am
by BigDumbDinosaur
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 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.
Re: C in a uC... what were they thinking??
Posted: Sun Jul 16, 2017 7:59 am
by Elminster
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.
Re: C in a uC... what were they thinking??
Posted: Mon Jul 17, 2017 11:41 am
by 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.
Re: C in a uC... what were they thinking??
Posted: Mon Jul 17, 2017 12:23 pm
by Elminster
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.
Re: C in a uC... what were they thinking??
Posted: Mon Jul 17, 2017 12:42 pm
by 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.
Re: C in a uC... what were they thinking??
Posted: Mon Jul 17, 2017 1:52 pm
by 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
Re: C in a uC... what were they thinking??
Posted: Mon Jul 17, 2017 4:39 pm
by BigDumbDinosaur
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