"Ken Smith" schreef in bericht news:dffbtn$8ll$ snipped-for-privacy@blue.rahul.net...
Graham choosed the worst example possible ;)
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
"Ken Smith" schreef in bericht news:dffcuq$8ll$ snipped-for-privacy@blue.rahul.net...
Okay, but the design of the system does not much to do with the choice of the language. It's not that C coders don't design and start right away with an empty main().
Asm macro's are (sort of) subroutines. If they are large and often used, they eat a lot of space as well. But they are a great help to avoid many silly coding errors.
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
It does have a lot to do with it:
Since C code is larger, slower and needs more RAM, it can force you to change to a micor that has more code space and a faster clock speed and add more RAM. This bigger faster micro would overheat the LM7805 so you have to put in a heat sink and use a bigger battery. The bigger battery and heat sinking changes the case.
Before you know where you're at, the entire hand held unit will fit in the back of a pick-up truck and cost about the same as the truck.
Macros only eat as much room as the code would have if you just copy and pasted them. In the ASM I use, the logic you can do in the conditional compile structures is enough that you can do things like this:
OrIntoStatus macro ErrCode
if low(ErrCode) > 0 mov DPTR,#Status movx a,@DPTR orl a,#low(ErrCode) movx @DPTR,a if high(ErrCode) > 0 inc DPTR end if else if high(ErrCode) > 0 mov DPTR.#(Status+1) end if end if
if high(ErrCode) >0 movx a,@DPTR orl a,#high(ErrCode) movx @DPTR,a end if
endm
The nice thing about this is that when the error code constants change, the recompiled code correctly changes the code sections to match.
-- -- kensmith@rahul.net forging knowledge
In article , John Larkin wrote: [...]
I'm sorry but the hardware guy has finished his part of the project and the micro is an CDP1802. :> Now what do you do?
If you are doing the hardware and the software, you can insure that the ADC input is dithered by something.
-- -- kensmith@rahul.net forging knowledge
You *don't* have the space for a look-up table ?
Graham
The number of internal cycles actually sounds similar to the result I got from the PL/M51 compiler.
The standard 8051 isn't as fast wrt the crystal freq though.
I inspected the code the compiler produced and concluded it couldn't be hand optimised any.
So, it seems you're saying you can't outrun my HLL example, simply equal it. Your choice of CPU is quicker compared to my 1989 example however. Of course
8051 family parts are now routinely available with 33 and 40 MHz clock options - not to mention a faster instruction cycle time vs clock speed. It would be easy to do the same task now in around 12-15us.Graham
Hello John,
That made me chuckle. Thinking about Forrest Gump ("That's all I have to say about that"). SCNR.
That's also why I often design stuff discrete. It takes out the not so documented habits of some chips, IOW the ones that marketing didn't like to see on the data sheet because it wouldn't look good. Like that LDO regulator that didn't like it when the source resistance got too high.
I always thought we'd be immune from that once we start our own business. About 15 years ago I realized that wasn't so. "Oh, can you make those two functions run simultaneously?". Take deep breaths, open the window no matter how cold it is, don't let the face get too red, bite on the lips so no profanities come out and all that.
Regards, Joerg
If it does that then it's no good. Don't blame it on being a HLL however.
My PL/M51 compiler is *brilliant* at minimising required RAM and is doubtless capable of 'tracking' RAM usage way better than an asm coder could.
Graham
They still even exist ?
Graham
Because that's what the compiler is designed to do ! ;-)
Don't even have a long word in PL/M51 !
I recently had to handle some 32 bit data on an 89S53 actually that was instruction code for a DSP. Easily handled in byte-wide chunks.
I do like PL/M's register level capability too - and stuff that's asm-like such as SHL and ROR.
Totally agred.
Graham
"Ken Smith" schreef in bericht news:dffnk0$kem$ snipped-for-privacy@blue.rahul.net...
Okay, you're now taking the hardware part into the design, where I assumed we were looking at software alone.
When you design the hardware, the selection of the uC also affects the choices for the programming language. Hey, you might even decide not to use a uC at all, Joerg knows all about that ;) But even the lowest budget MP4 players (pocketsize with LCD) have multi-megabytes of flash, extremely fast hardware etc. And probably 98% of it coded in C. I even see a tendency to program more in interpreted script languages (perl/php). The required complexity simply demands for such choices. The areas where asm is the way to go, are getting smaller and smaller.
A typical cell phone isn't that large... You certainly don't want to write such software in asm alone. The damn thing would never never get finished.
You can do similar tricks in C if need be. Pre-processor tricks are endless. Obfuscated C contests are full of it. One-liners that behave as complete basic interpreters and what have you ;)
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
"Pooh Bear" schreef in bericht news: snipped-for-privacy@hotmail.com...
it.
course
options -
easy
HLL often produces amazingly effective code. A divide by 7 results in a bitshift >> 3 + add instruction, for instance. Much in the same way an asm coder would do it.
But there are things to watch out for. It is very easy to use
32bit variables on an 8 bit micro, when using a HLL. This can result in very lengthy asm code, slow as hell. Same goes for floating point, don't use it unless you really really must.It pays off to know what you're asking from your compiler. And occasionally check what code it produces isn't a bad idea. This is even more important on smallish uC's like 8052, PIC etc.
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
In article , Frank Bemelman wrote: [...]
Since I usually end up doing both, it is sort of natural for me to think that way. If I was just writing software and could specify someone else to make any hardware I wanted, I could still use ASM.
LOOP_WHILE_DOING_IT ; Thats all I need :>
If I had a custom micro in an FPGA, it could have one instruction to do the whole product. The FPGA design could be done in VHDL which is actually a higher level language than C. Funny how things tend to go full circle.
You should switch to APL. Many years ago, just to prove a point, I wrote an entire Tic-Tac-Toe game in 4 lines of APL.
[...]
Did you know that they stopped having that contest when Window98 came out? The figured there wasn't a point anymore.
-- -- kensmith@rahul.net forging knowledge
Isn't it actually the linker that does the RAM overlay function?
BTW: Don't bet on the PLM51 compiler doing better than an asm coder.
-- -- kensmith@rahul.net forging knowledge
You can still buy freshly minted ones.
I'd bet it wouldn't take much of an FPGA to mimic an 1802.
-- -- kensmith@rahul.net forging knowledge
In article , Pooh Bear wrote: [....]
In my current project I could fit it. In the previous, all the code space was full plus some.
-- -- kensmith@rahul.net forging knowledge
You may be right there. RL51 does get called at some point. I never looked into it that hard. There's several levels of optimisation available as compiler directives too.
Probably wouldn't outperform a very good one for sure.
I do however have a reasonably large application that runs on an 8031 and I would defy an asm coder to keep track of all the shit going on in it and maintain efficient lifetime dependent variable optimised use of RAM too..
I honestly don't think it would be maintainable in asm, and most likely very hard to write bug free.
Graham
When I have over a decades accumulation of tested bits of (8051) code and a profound loathing of "C" I don't see the point in using anything else (old dogs, tricks etc). Whatever gets the job done and the bills paid. M
Did not have time in that particular case.
S
-- Well, that doesn\'t necessarily mean it _couldn\'t_ it just means you couldn\'t figure out how to tighten it up. ;)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.