SX and C
KenM
Posts: 657
I have a question related to programming language and the SX.
As I understand, there are compilers that will compile C written code for the SX.
Excluding cost of software or compilers, from a programming standpoint, what advantage(s) or disadvantages(s) are there to Assembly versus C for the SX.
Is it that a programmer may simply be more efficient with C to write the same code functionality as an assembly written program?
Just curious.
Ken
As I understand, there are compilers that will compile C written code for the SX.
Excluding cost of software or compilers, from a programming standpoint, what advantage(s) or disadvantages(s) are there to Assembly versus C for the SX.
Is it that a programmer may simply be more efficient with C to write the same code functionality as an assembly written program?
Just curious.
Ken
Comments
all compilers for every processor based device do the same thing: allow the programmer to work in a more intuitive form of code but ultimately have that code translated to the native machine code of the target device. In this case, the programming language C.
In assembly code, you have intimate control of how the processor will perform a task. A task can take one step / cycle or many for that matter. When working with C or any other language, you can create the same tasks, however, the effort to convey this information is usually far less.
Take the following example in C:
result = integerArray[noparse][[/noparse]index - 2];
Here we have an array of integers, one of which will be assigned to the variable (or register) 'result'. The element number of the array that is assigned to result is given by the evaluation in the brackets, two less than the value of the variable index.
Even though this description of the above can seem long in words, it is a relatively simple statement.
Imagine what is involved in assembly code:
1. switch to the bank of the integer array
2. place the base address into the fsr register
3. switch to the bank that index is in
4. subtract two from that value and store
5. get the stored index value and perform all bank jumps required
6. add the offset to the fsr
7. read the value of the array element from the ind register
8. switch to bank containing result and store the value
It is evident that most of this operation is completely hidden in C. In fact, the compiler will create assembler code that will perform similar steps. Many debugging problems come from errors in program flow. The C compiler takes care of this task for you and will never make a mistake. You are usually left with true algorithm errors to debug rather than jumps and banks. The compiler has the advantage of easily and quickly analyzing a program, deciding where to put variables so that few bank switches are required and determining which registers can be reused at different parts of the program to save space.
In short, you are focused on the results rather than the means of reaching it.
As for the cons, you have very little control of how the compiler performs a task. If a task must be done at grease lightning speed, its possible that the compiler will not utilize the fastest method that you have in mind. Thankfully, compilers generally allow you to add segments of assembler into the C code for such occasions. The efficiency of the compiler is only as good as the programmer behind it.
Personally, I have found that since I have started working with C, I've found it more difficult to go back to assembly code. Even simple projects that require code as simple as a state machine are much easier to develop and maintain in C than assembler saving time and money.
Hope this little speech answers some of your questions.
Kevin
Thank you for the thorough "speach." It answers my question perfectly.
Ken
Kevin provided a good explanation, I'll try to bullet the points some will be the same as Kevin's.
Pros of assembly:
Pros of C:
The obvious optimal solution is using C while writing core components in assembly. You may notice I listed abstraction (points 4 in 1st list and 2 in 2nd) as being both a con and pro, there has been a debate in the programming community over what level of abstraction is the best, but this argument is primarily·between·C and higher level languages like fortran or java).
Paul
PS. Id love to see a java interpreter developed for the SX (Yes I know parallax has the Javalin and there are a few others but Im not prepared to shell out that kind of money at this point)
One particular disadvantage to the use of a compiler on the SX chips is their terribly small code size, at least when compared to chips like the newer PIC 18F series.
One thing to consider is extensive use of Macros. I'm only just getting started with microcontroller assembly, so I cannot comment specifically on the macro capabilities of SASM, but I do know that an assembler with good macro facilities can approach the ease of use of C, while still providing the speed and small code size of assembly.
-p.
Thanks for the excellent explanations, now I clearly understand the reasons to use one or the other....which now brings me to another question.
Does the increased ease of·writing the program in C extend to math, floating point and such?
For me, any 16, 24, or 32 bit math is nearly impossible. Lucky for me....I·have been able to use routines from SXLIST.com
From what I remember about my one school semester of C, and ignoring all the other nuances, I can certainly see how writing the program in a C could definately saved me some hours.
Maybe I just answered my question as I looked for some compilers and found this
http://www.parallax.com/detail.asp?product_id=45206
After I googled SX C Compiler, there are too many choices.
Any suggestions on reliability, ease of use etc? I would assume the ByteCraft guy sold by Parallax is a proven unit?
Ken
I forgot to mention·it works for·both PIC and SX. [noparse]:)[/noparse]
Chris
Post Edited (CPUMAN) : 9/17/2004 3:42:50 AM GMT
Ken Gracey
Parallax, Inc.
http://www.sxlist.com/techref/ubicom/sasm.htm for SASM or SXKey with SASM. SASM allows much more powerfull macros:
Optimized ·conditionals(IsZero,Eq,Lt,LE,IsNotZero,NE,Gt,GE) and structures (IF, ELSEIF, ·ELSE, ENDIF / REPEAT, WHILE, UNTIL / SELECT CASE)
Automatic·Memory management, tables, compressed ·tables, automatic pageing, multiple register moves, stacks, buffers.
Delay (usec,msec,sec,cycles) and ·timers
Port setup ·(in,out,pull,float,cmos,ttl)
With these macros you can write code like this:
·port ra, ttl, in, pullup, %10001000
·port ra, ttl, out, %01110111
·repeat
·· clr·frA
·· repeat
···· xor frA,·frB
···· until frD, LEN,·frA
·· until frC,IsNotZero
·DoSelect
·DoCase iA,eq,iB
·· clr·iC
·DoCase iD,eq,iE
·· clr·iF
· ·DoIf iG,EqN,iH
···· clr·iI
··· DoElseIf iJ,Lt,iK
···· clr·iL
··· DoElse
···· clr·iM
···· DoEndIf
·DoCaseElse
·· clr·iC
·DoCaseEnd
·gotow :ONE, :TWO, :THREE, :ONE, :TWO, :THREE
; BinJump <reg>, <Address> [noparse][[/noparse], <Address>]
;· Call with the first parameter of the register to tbe tested and
;· the following parameters a list of addresses to jump to based on
;· the value of the register.
;· More effecient than a long jump table for 4 or fewer addresses
; GotoW <Address> [noparse][[/noparse], <Address>]
;· Implements a jump table using space in the first low half page of memory.
;· must be invoked after all <Address>'s are defined.
;· Uses BinJump for less than 5 addresses
; Condition enum (IsZero,Eq,Lt,LE,IsNotZero,NE,Gt,GE,EqN,LtN,LEN,NEN,GtN,GEN)
;· enum values ending in N indicate that the second operand will be a constant
; Condition := [noparse][[/noparse]<reg>, <enum> | <reg>, <enum>, <reg> | <reg>, <enum>, <constant> ]
; Skz <reg>, [noparse][[/noparse]IsZero | IsNotZero]
;· Generates a skip if the reg is zero or not zero
; Skc <reg1>, [noparse][[/noparse]Eq | Lt | LE | NE | Gt | GE], <reg2>
;· Generates a skip if reg1 compaires as specified to reg2
; Skc <reg>, [noparse][[/noparse]EqN | LtN | LEN | NEN | GtN | GEN], <constant>
;· Generates a skip if reg compaires as specified to constant
; StackPUSH, StackPOP, StackTOS and stack1...
;· Provide a compile time stack to record and retrieve the addresses of
;· locations were jumps need to be compiled once the jump-to address is
;· known. Used by the following macros:
; Repeat
;·<statements>
;·[noparse][[/noparse]forever | while <condition> | until <condition>]
;
;· compiles Skz or Skc with jumps to implement a structured loop
; DoIf <condition>
;·<statements>
; [noparse][[/noparse]
; DoElseIf <condition>
;·<statements>
;·]...
; [noparse][[/noparse]
; DoElse
;·<statements>
;·]
; ·DoEndIf
;
;· Compiles Skz or Skc with jumps to implement a structured conditional
;· As many DoElseIf statements as desired may be included because each DoElseIf
;·· links to the next one at run time so that if the first DoElseIf condition
;·· is true, after its statements a jump will be compiled that will jump to
;·· the simular jump after the next DoElseIf statements. To avoid this extra
;·· run time, use DoSelect.
; DoSelect
; [noparse][[/noparse]
; DoCase <condition>
;·<statements>
;·]...
; [noparse][[/noparse]
; DoCaseElse
;·<statements>
;·]
; DoEndSelect
;
;· Compiles Skz or Skc with jumps to implement a structured conditional
;· A limited number of DoCase statments can be compiled because each
;·· case compiles a jump to the end of the select after the statements
;·· following the case condition and recording the position were these
;·· jumps must be org'd takes up space on the "stack" provided by
;·· StackPUSH, StackPOP and stack1...15
; CycleFor <count>
;· if the count is less than the interrupt period, compiles a delay loop of the
;· required cycles. For large delays, compiles code to set up to a 3 byte timer
;· to an interrupt count equal to the delay and then waits for the counter to
;· zero.
; Delay value, [noparse][[/noparse]usec,msec,sec,cycles]
;· Calculates cycles from delay value and units (milli seconds, micro seconds,
;· or seconds). Calls cyclefor to delay that number of cycles
·delay 2, cycles
·delay 2, usec
·delay 2, msec
·delay 2, sec
·delay 999, sec
; DecBufPtr <ptr>
;· decrements buffer pointers and keeps them within one bank
; IncBufPtr <ptr>
;· increments buffer pointers and keeps them within one bank
; mmov <src>,<dest>,<Count>
;· Multi Move moves src to dest for count bytes.
; LookupW <12bitValue> [noparse][[/noparse], <12bitValue>]
;· uses IREAD (affecting M and W) to lookup values up to 12 bits indexed by W
; Subroutine
;· Defines SubEntryAddr from the current address or the address of a jump from
;· space in the first low half page of memory as needed to ensure global
;· CALL access to a subroutine.
; Push, Pop
;·· compile code to push and pop W from a stack setup in one register bank.
; Port r[noparse][[/noparse]a | b | c | d | e] [noparse][[/noparse]in | out | pull | float | cmos | ttl] bits
;· sets the port mode and configuration for standard pins
And in just about every case, the code compiled is the absolute best possible. It takes into account just about every trick in the book and several that are not.
If I had the time, I'm pretty sure I can write a LET macro, as in:
LET frA, = , frB, +, 9
See
http://www.sxlist.com/techref/expeval2.asp
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
Me too. And a few others, too!
I was just doing a bit of marketing research . . .
Let me see what we can do.
- Ken
Paul Post Edited (Paul Baker) : 9/21/2004 5:56:24 AM GMT
But seriously (?) now...
I really think a good macro and subroutine library is the way to go for a chip like the SX. It might take a little while to get up to speed with these tools, but I I'm sure the results will be well worth the effort spent. Many thanks, James, for the links. I'll definitely be checking them out!
Has anyone ever done anything for the SX like the Sweet-16 interpreter that Woz wrote for the Apple2? The Sweet-16 was a pseudo 16-bit machine that was interpreted by the 6502. The SX's IREAD instruction would make this possible. The overhead for the Sweet-16 interpreter was remarkably low, and codesize was remarkably tight compared to macro expansion.
Another thing to consider is Wouter van Ooijen's "Jal" language. I haven't played with it myself, but I certainly do intend to check it out once I've got more of a handle on the low-level stuff...
One of the big advantages of the SX over other microcontrollers seems to be it's interrupt handling capabilities. (I say "seems" because I've only been playing with microcontrollers for little more than two weeks now, and the SX is the only hardware I have...) I'm a huge fan of interrupt/event driven programming and I think one of the most critical features of any higher level programming language for the SX would be strong integrated interrupt support.
-p.
Sweet 16 for the SX is an EXCELLENT idea! There are a few... err... sorry, I got distracted by the emoticon parade again.. where was I? Oh yes, there are a few token languages out there but it is a technique that is very underused and which I have been seriously thinking about encorporating in to a macro set as a way to provide 16 or even 32 bit versions of some of the comparison operators or possibly for math, especially as it would relate to the expression evalulator and code generators.
http://www.sxlist.com/techref/expeval2.asp
Just so others are clear on the idea here, sweet 16 was actually just a collection of subroutines which sort of emulated 16 bit versions of some of the 6502's 8 bit instructions. You can write "code" in these by compiling a list of the starting addresses of those routines and using IREAD to sequence that list and call the routines. The routines do things like adding, subtracting, etc... but rather than doing that with one register at a time, they do it on two or 4 or whatever. For example, one routine might take the register pointed to by FSR and add that to a "WLOW" register which has been set aside as the low 8 bits of a 16 bit "fake" accumulator then continue and add the next register (after incrementing FSR) to·"WHIGH"
Next, if you like, you can assign a mnenomic (e.g. "add16") or token (e.g. $1C0 ) along with a target parameter (listed after the "add16" as in "add16 ra,w" or added to the token as in $1D5) and write a program that translates the new menomics or tokens into calls to the appropriate subroutine. That translation is easier than you might think because you can use macros to translate the menomics·or a lookup table to translate the tokens. The only difference is that one happens at compile time and the other at run time.
The token / run time translation idea is my suggestion (seperate from the sweet16 idea) and may seem to be dumb at first, but it does have one or two advantages:
A) tokens CAN take less code space since, for example, a 16 token "language" could store 3 tokes per word and, actually, the tokens do not have to reside in internal memory. This is how the BASIC Stamp can have a very large and re-programmable without a programmer memory. Please note that I don't see any reason for re-inventing the Stamp, that one has been done and done well.
http://www.al-williams.com/paklib.htm·and by the way, I strongly recommend the PAK CoProcessors.
But it can be·targeted to IO processors or special function. I've started in on such a thing for a device programmer at
http://www.sxlist.com/techref/piclist/cump/bytecode.htm
And there are other examples of that sort of thing at
http://www.sxlist.com/techref/language/meta-l/bitscope.htm·Test equipment
http://www.oricomtech.com/ictc-cmd.htm·General IO
http://www.sxlist.com/techref/language/meta-l/npci.htm·General Computing
http://www.sxlist.com/techref/piclist/andrewspicos/index.htm·Testing
Finally, your mention of this reminded me of another language that is just so darn cool I would love to see it used more:
http://www.sxlist.com/techref/language/xpl0.htm
XPL0 is cool because it has been ported to so many processors. You can write the same program and run it on 6502, 8080, 6800, PDP-10, IBM-360,· 65802, 680x0, PIC, SX28, and the 80x86 family. GUI support and win32 versions are also available. It is almost like java in terms of its portability (not anything like it syntax wise) and it is sort of like Pascal in terms of the source language. This history is neat:
http://www.sxlist.com/images/org/6502group/http/HIST6502.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!