Macros are far more than (even sort of) subroutines. They can do conditional processing too. A few years back (when I was doign such things) I had a set of x86 assmebler macros that would do PL/I-like branch constructs (IF/THEN/ELSE, SELECT/WHEN in both forms, LOOP, UNTIL, etc.). Assembler macros are *much* more than (sort of) subroutines. If that's all you're using macros for, I can see why you don't much like ASM.
-- Keith
...which is no different than microprocessor development, other than we hardware types also have the "how much will it cost?" complication thrown in.
-- Keith
What do you code your 8051 in ?
Graham
John Fields skrev:
snip
I'm not what all the fuzz is about use ASM when it makes sense, use C when that makes sense.
C code is only as bloated as you make it, depending on how you write your code the compiler can be a little more than a some what intelligent assembler with a portable language.
So ASM usually gains very little except in a few cases
I downloaded a demo version of cosmics 6805 compiler, compiling
unsigned char result; unsigned short a; unsigned short b;
@interrupt void _Isr(void) { if(a==b) result = 1; else result = 0; }
Produced:
b603 lda _a+1 b101 cmp _b+1
260b bne L52 be02 ldx _a b300 cpx _b 2605 bne L52 a601 lda #1 b704 sta _result 80 rti L52: 3f04 clr _result 80 rtiNot too bad ....
-Lasse
--
It\'s not _the_ status register, Frank, its simply a location in RAM
used to store the status or results of various operations. I though
I made that clear by allocating space for it:
;Motorola 68HSC705C8A:
;*****allocate RAM:
org $0050 ;start of RAM
lobytea ds1 ;storage for low byte of word a
hibytea ds1 ;storage for high byte of word a
lobyteb ds1 ;storage for low byte of word b
hibyteb ds1 ;storage high byte of word b
temp ds1 ;temp register
status ds1 ;status register
BTW, I went and looked up the address of the start of the main block
of RAM and included it, above, insteas of leaving it as $XXXX.
snipped-for-privacy@ieee.org wrote: ....
Of course that can be shortened 3 bytes, to:
where I've put ?? in place of digits I don't know offhand.
-jiw
Try PowerBasic. The DOS version is perfect for quick math and text crunching programs. We use it for all our realtime test programs.
They have a Windows thing, too: PbWin is the compiler, and PbForms builds Windows interfaces (all the usual pulldown boxes, clickie things, etc) and saves the necessary source code. It's like VisualBasic except that it's a real compiler that makes a single, tiny Windows .exe file, without any silly install crap or runtime dll's.
PbWin and PBCC (the console-mode compiler) do Ethernet/TCP/IP, quick and easy, too.
John
What kind of abrasive wheel do you use to round off all the bits?
-- Paul Hovnanian mailto:Paul@Hovnanian.com ------------------------------------------------------------------ Telemark: If it was easy, they\'d call it snowboarding.
I've had to look into the subject to fix a problem with some interrupt code. The Keil C51 does some of the work in the compile step but most of the actual assigning of overlayed addresses happens at link time. When you think about it, it is obvious that this must be so because the routines you call may be in a different file.
The Keil stuff doesn't seem to be smart enough to be able to handle overlaying across files in the interrupt code.
A lot depends on the nature of the program. In some programs, a lot of the variables are fixed and can't be overlayed. In one project I did, only 12 bytes were needed for the overlayed stuff. Almost everything else was a running total or the like.
When you manually overlay RAM, you have to comment the code very well on the subject. Basically you extend what you do for registers like this:
;******************************************************** ;* ArcTan * ;* * ;* This rountine takes the arc tangent of the input * ;* * ;* Input: * ;* R1 The address of the XXXX.XXXX input * ;* R0 Where the XXXX.XXXX output goes * ;* * ;* Output: * ;* R1 incremented by 4 * ;* [R1] written * ;* R0 incremented by 4 * ;* R2 zero * ;* R3-R7 trashed * ;* Work1 trashed * ;* Work2-4 Preserved * ;********************************************************
-- -- kensmith@rahul.net forging knowledge
"John Fields" schreef in bericht news: snipped-for-privacy@4ax.com...
The advantage of using a compiler here, would perhaps be that a compiler would not use the status bit to return the result, as the status bit is used all over the place. Your interrupt is for sure going to mess up everything.
Of cource, it would be fixed and never leave the lab. Also, this example is so simple, that even the worst compilers would produce decent code for this. Perhaps it would use a SUB and JZ, probably not a temp variable, and a double RTI too. I don't know the 6805, does it not have a Branch on zero ?
I don't have a 8051 compiler installed now, otherwise I would give it a try and post the result.
Perhaps someone can try this:
uint8 result; uint16 a; uint16 b;
void interrupt() { if(a==b) result = 1; else result = 0; }
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
It's the duckling syndrome. We always love whatever we bonded to as a child.
I like C because it's what I 'grew up' with. I've done lots of asm coding, but it is always painful when I have to hack out the loop control structures yet again using compare and branch instructions (or write the macros using some arcane assembler to do that on a new architecture), or explicitly allocate and reuse local variables, or remember which status bits get whacked by which instructions, or try to remember the calling registers or stack allocation for a called routine.
C does all this for you, at a small price in efficiency, but doesn't get in your way like many other HLLs. I think the level of abstraction is just right for most software that touches hardware. That is probably why most OS, driver, and embedded software is written in it, and has been for 25 years. If you need more speed or more space, there are hard core optimization options, and you can always profile and optimize by hand in assembler.
Yet another good thing about C is that it's pretty standard. Nearly everybody can read it after a few minutes instruction (unless you've macroized it to look like cobol) Assembler with macros tends to look like a private language, and intuiting higher level structures can be daunting.
C was designed to be a portable assembly language, and, in my opinion, does a great job at that task, and many others. Quick to write, often portable, easy to read, handles annoying details that can be the source of bugs, but lets you whack away at hardware without trying to protect you from yourself. Flexible, malleable, can be used to write drivers, operating systems, or AI. It's a good language.
--
Regards,
Bob Monsen
If a little knowledge is dangerous, where is the man who has
so much as to be out of danger?
Thomas Henry Huxley, 1877
Well, the 0's are already round, and I have a program that turns all the 1's into 8's. I did learn to program first in octal.
John
Not at all. I had all of two weeks of PL/I in college and perhaps another week (40 hours class) OTJ. Otherwise I've never used it. I *do* like PL/I language constructs though. Pascal, I was moderatley comfortable with. I was riased with Fortran, so Basic is trivial. ASM is comfortable because that's what I do; sling bits. I really don't care what the processor is, it's a small learning curve to be productive (particularly the embedded stuff). VHDL is nice because it's *NOT* 'C'. ;-)
You're not structured enough. It's been years since I had problems with asm stuff, yet 'C' will allow even the most experienced programmer to shoot himself with pointers without knowing better. I can't tell you the number of times we have hard crashes going form one OS (or compiler) version to another because different assumptions are made WRT pointers. Crappy programming, agreed. I don't see experienced ASM programmers making the same stupid mistakes. They *know* what a pointer is and to treat it with respect.
I dissagree. Most work that touches hardware is done in 'C' because programmers are too dumbed down. ;-)
Hmm, tell that to IBM. MVS is written in PL/S (or PL/AS), which isn't much more than a macro language on top of 370 assembler. If the macros are written correctly, they work just fine.
I'd like to see you argue that point over on comp.sci. They chew people up with that attitude (though personally I don't disagree, much).
It sucks as an embedded language. It might be OK (with the ++ crap added on top) for UI stuff, but it is crap as an embedded language.
-- Keith
I read in sci.electronics.design that Bob Monsen wrote (in ) about 'Hey, what is all this 'off topic' posting?', on Mon, 5 Sep 2005:
That's why I like BBC BASIC, even if no-one else does.
-- Regards, John Woodgate, OOO - Own Opinions Only. If everything has been designed, a god designed evolution by natural selection. http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
Administratium. It grinds everyone's bits.
-- Keith
"John Fields" schreef in bericht news: snipped-for-privacy@4ax.com...
Ah, that makes a difference ;)
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
schreef in bericht news: snipped-for-privacy@g43g2000cwa.googlegroups.com...
Well, it sure beats the handcoded version of John ;)
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
"John Woodgate" schreef in bericht news: snipped-for-privacy@jmwa.demon.co.uk...
That's a good enough reason.
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
PowerBasic.com!
If you want to do typical engineering stuff, I'd just go with the DOS version; it works fine under Windows. It runs useful FOR loops at 10 MHz on my Pentium.
John
I read in sci.electronics.design that John Larkin wrote (in ) about 'Hey, what is all this 'off topic' posting?', on Mon, 5 Sep 2005:
I will investigate. Do you have a preferred source? Thanks.
-- Regards, John Woodgate, OOO - Own Opinions Only. If everything has been designed, a god designed evolution by natural selection. http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
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.