smallc compiler for sx28
Peter Verkaik
Posts: 3,956
Hi,
I have ported the smallc compiler to generate sasm assembly files.
The program compiles with the free C++ builder 5.5 available at
www.borland.com
This port still lacks some runtime routines for 16bit comparisons.
I think I have solved the ram bank problem. The sx28 memory is
treated as one block of 128 bytes (global ram is for runtime env.)
I invite anyone to download the free BCC compiler from Borland
and give it a try.
This smallc port supports chars and ints, 16bit integer math
(compare routines are still lacking) .
Still a few problems such as calls to any location. I hope you
come up with some ideas to make this another fine tool for
the SX.
I'd like some ideas on how to tackle the page call issue.
I believe James Newton has some macros for this but I could
not locate these on sxlist.com
Also any optimization tips are welcome.
And I do need the 16bit compare routines (signed and unsigned)
regards peter
ps. The sccsx.c file has been updated
Post Edited (Peter Verkaik) : 12/30/2004 8:51:50 PM GMT
I have ported the smallc compiler to generate sasm assembly files.
The program compiles with the free C++ builder 5.5 available at
www.borland.com
This port still lacks some runtime routines for 16bit comparisons.
I think I have solved the ram bank problem. The sx28 memory is
treated as one block of 128 bytes (global ram is for runtime env.)
I invite anyone to download the free BCC compiler from Borland
and give it a try.
This smallc port supports chars and ints, 16bit integer math
(compare routines are still lacking) .
Still a few problems such as calls to any location. I hope you
come up with some ideas to make this another fine tool for
the SX.
I'd like some ideas on how to tackle the page call issue.
I believe James Newton has some macros for this but I could
not locate these on sxlist.com
Also any optimization tips are welcome.
And I do need the 16bit compare routines (signed and unsigned)
regards peter
ps. The sccsx.c file has been updated
Post Edited (Peter Verkaik) : 12/30/2004 8:51:50 PM GMT
Comments
Terrific! I had been toying with this idea in my head for some time. Glad to see someone actually did it. I just tried compiling it with VC++ and it works just fine.
One problem is that the test file doesn't assemble properly due to label "_21" being used twice. In addition, the labels it generates get out of sequence around that part of the generated source code. Is this part of the missing 16 bit compare routine issue or something different?
Thanks, PeterM
That _21 label issue has been resolved. Just download sccsx.c again.
The sequence of internal labels is set by·parse events, the output
is delayed and re-ordered. It is a bit annoying, but·not that much.
The runtime code is called correctly,·only the comparison
entries just do ret.·These must just be included at the proper
places to get the lot working so I can really debug it (particularly switch)
I was thinking of letting globals be definad as equ, with values 0-127
Because access·for locals is done through the primary register,
could that also do for globals. No more bank to worry about!
That leaves the page call issue.
Any thoughts?
regards peter
http://www.sxlist.com/techref/ubicom/sasmtemp.src is the overall template and the macros for page management are in
http://www.sxlist.com/techref/ubicom/sasmmem.src·in the Subroutine macro and for tables the LookupW macro
The BinJump and GotoW macros were originally used for table lookups, but after a lot of messing about, the LookupW macro does so much better that I just use it all the time.
Calls to any location can now be done with the "secret" instructions or by some adaptation of my "Subroutine" macro. The macro isn't doing rocket science... it just needs to get called at the start of each subroutine, then it looks at the current address and if it is not in "reachable" space, it assembles a long jump to the start of the subroutine in a reserved area in lower memory and returns the address of that jump as the address to call for the subroutine.
Did that make sense? If you can't directly call the sub, call a jump to the sub which has been placed where you can call it. sasmtemp.src sets aside that area for the jumps and sasmmem.src:Subroutine assembles the jumps and you substitute the address it returns for the actuall address of the subroutine.
Here are the important bits extracted...
Now that really isn't that complex is it? No more subroutine call problems, the amount of space used for the LowHalfPage table can be adjusted to exactly match needed after the program is complete so no memory need be wasted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!
Post Edited (James Newton) : 12/30/2004 9:40:27 PM GMT
For people who MUST use C and can afford a real SXC compilers (see
http://www.sxlist.com/techref/ubicom/languages.htm·for a number of low cost options) or want to mess about with compiler programming, this is great!
For the average user who wants to get a fast bit of code out the door without learning assembly, I would stick to SX/B.
And, of course, for pros who need the fastest possible asm code without the headaches associated with asm coding on the SX, the macros listed above at SXList.com are the best! (he says with all humility... :SNORT[noparse]:)[/noparse]
PM, if I could get you to add an ability for SASM to break macro arguments into individual letters, I could write a LET macro that would do expression evaluation...
For the 16 compare thing, see
http://www.sxlist.com/techref/ubicom/lib/flow/compcon_sx.htm near the bottom of the page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!
The smallc was written for cpu's with 16bit registers. Since I know
the Z80 I used HL and DE. I could have used the 80386 AX and BX
but this gives two X's. True, the code is not optimal, especially not for
bytes. (are converted to int for expressions). However, you could
create a byte only version (no ints) but with the use of while, for, do
switch and arithmetic operators.
Thanks for the compare url's.
regards peter
Time to test the lot with sxsim.
regards peter
not a single bank instruction and ram banks 0 to 7 appear
as a contigues block of 128 bytes.
Also updated the logical test routines so true or false is
directly known via the Z flag.
Global variables now get a logical address (0-126) which
is the offset inside the contigues block.
The only problem still is the call across pages.
Question to Gunther:
Is it possible to let Sxsim have a flat memory model mode
(turn off page call boundary checks and lower/upper half page check) ?
That way the logic of a program can be tested without having errors
regarding the location of some code. Once the logic is ok you can move
around code to satisfy page and lower/upper half requirements.
(and it would let me test sccsx generated files easily).
regards peter
I've been, well, pushing, these macros for a long time and either people just aren't understanding (which seems amazing to me) or I'm missing something basic about why they won't work for these sort of problems (which seems more likely but still amazing) but in either case, they aren't getting used as far as I can see.
Please take a moment to try to tell me why?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!
I can't speak for anyone else, but I have a thought about the macros. When they are described, they sound like a really cool idea in that they take away a lot of drudge work from the programmer. However, when you actually go and look at them, I think most people are perhaps shocked to see how extensive the whole package is.
Remember, since these are people who are programming in assembly language, I think a lot of folks are reluctant to include a group of macros whose source code is probably bigger than the project they are working on. Now, I'll grant you that most of it probably never even gets assembled in due to the extensive use of IFDEfs, but nonetheless, the macro package is mighty big.
The size leads me to me next possible explanation which is that not everyone is as comfortable with the SX macro language as you are. Just trying to read the macro source code is challenging, and I believe that many programmers don't really feel the need to learn another "API" just to program in assembly language.
Please understand that this doesn't diminish the quality or usefulness of the macro package. I merely am trying to offer some possible reasons that they haven't been embraced as readily as you would hope.
I believe this is all related (generically speaking) to the power/usefulness of open source code. While we all want access to the source, the vast majority of programmers do little more with it than run the make file to build it. Frankly, I think it's harder to honestly comprehend someone else's code than it is to simply write the damn thing yourself.
For example, of all the people on the old SX mailing list who griped about wanting Parallax to open source the SXKey so they could improve it, how many actually did anything with the code? I'm pretty sure the answer is - one. To the best of my knowledge, no one else on the planet seemed to actually take the bull by the horns and start learning, modifying, and improving the SXKey other than myself.
As a final note, to anyone who feels that my last couple of paragraphs were an insult or attack on open source coding, let me ask you to stop and re-read everything I wrote. I'm not saying open source is a bad idea, merely that it's limited by the fact that most people are unwilling to put in the hard work and do something with it. However, I applaud and appreciate the open source community and the incredible work that has come out of it.
Thanks, PeterM
PS - Using some of your macro solutions may in fact be completely ideal for Peter Verkaik and the SmallC compiler modifications he has made.
Wow, you hit the nail on the head for me.....
The macros would appear to indeed be very useful, but for a hack like me, you brought up several points that explain exactly why I have not tackled using macros.
examples;
Peter wrote: "I think most people are perhaps shocked to see how extensive the whole package is." Definately the case for me.
And Peter also wrote: "I think it's harder to honestly comprehend someone else's code than it is to simply write the damn thing yourself." Again, this fits me to a tee.
And....."The size leads me to me next possible explanation which is that not everyone is as comfortable with the SX macro language as you are."......Definately the case for me.
And, James......that is why I would like to see a "tutorial" on creating my own macros I can use exclusivly for my SX18 and SX28 projects, hence my previous request for such in an upcoming·monthly (jab - poke) sxlist newsletter.
Also James, being a lowly financial contributor to SXlist, my previous comment is indeed just a friendly poke in the ribs......we are all very busy, please don't take my comment the wrong way, as you previously offered "money back," which I did not request, nor will I request it.
Probably foolish on my·part, but I have not yet embraced/used the new SX/B compiler. For the rank hobbyist such as myself, I actual enjoy beating my head against·my·desk·getting my assembly code programs to·work, such as writing my own shift in and shift out routines, and hacking 16 and 32 bit math routines I get from SXlist.·Maybe it has to to with some kind of sick desire to have full "control" over what I want the SX to do.....no black boxes used here, unless I make the box myself.....hence create my own macros.
I have read Guenthers book regarding the use/creation of macros, but I guess that I just don't get it.
Happy Holidays to all.
Ken
Your call macro may work, problem is the smallc was written for
a flat memory model and thus it currently has no way of knowing
when code crosses a page boundary. I think I can solve that by
keeping a global sxpc variable that holds the current sx pc value
based on outputted code lines. That way I can insert a jmp @
just before a page end into the next page, even if that splits up
a subroutine.
I took a look at the code produced by the sxwiz basic compiler and
that generates a jump table in the lower half of page #1 for all defined
·subroutines in the program. That appears to be exactly what your
macro could do for smallc.
Other problem, the switch statement reads the address to jmp to
using iread. It looks the only way to do this jump is the use of a
secret instruction and reti, sacrificing the ability for sxkey debugging.
Now I think of it, the compiler can pass the address to call to a call_relay
routine from which all routines are called. Is that possible?
I prefer not to use the secret instrctions.
Any thoughts?
regards peter
Peter,
your question made me aware of another SxSim bug - for now, it actually supports the "flat memory model" when the PC register overflows from $ff to $00, i.e. in this case, it simply continues executing the first instruction in the next page (which is not how the "real silicon" behaves). You may name it a "feature" but it is actually a bug.
I considered to make the "flat memory model" an option in SxSim, as you had requested, but I did run into some hard to handle problems when dealing with RETs, and JMPs back to locations outside of the currently selected bank. Therefore, I decided to fix the current bug in SxSim instead, and to forget about the "flat memory" option.
I'm sorry that this not the message you might expect, but in the end, I think it would be better to make sure that sccsx generates code that a "real" SX can execute.
A Happy and Successful New Year to all forum members!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Thanks for looking into it anyway.
And it is no longer necessary. I made the compiler aware of the number
of words for outputted code. I now generate a page jump at the
end of a page to the start of the next page, until $7FF gets crossed,
at which point an out of memory error is displayed.
Also, all functions are now called via a callf routine in the lower half
of page 0, so functions may reside anyware.
The generated code is not optimal, and this is mostly because all vars
are treated as ints internally. I think that if I make the default type char
(also for expressions) alot of code space can be saved.
But to the compiler the SX28 appears to be a CPU with 2KB flat memory
codespace and 128 bytes flat memory ram. That is a big plus.
regards peter
I have renamed the primary register from HL to BC
for easier debugging with sxsim.
So system registers are now
fI equ IND ;fsr is normally $FF so fI is last ram byte
fA equ $0A
fB equ $0B
fC equ $0C
fD equ $0D
fE equ $0E
fSP equ $0F
fSP holds a logical address of a ram bank byte (0-127).
The labels above the sxsim ram bank display show the real address.
Gunther, would it be possible to have a hot-key (for example ALT+R)
to toggle those labels between 1x 3x 5x .. Fx and 0x 1x 2x .. 7x
That would be really helpful because I usually also apply logical
addresses in my assembly programs.
regards peter
Post Edited (Peter Verkaik) : 1/2/2005 1:33:49 PM GMT
Peter,
yes I can do this quite easily - it will be available in the next version coming soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
The page problems only come in when you try to use 8 bit wide instructions to do math or assignement on the 11 bit PC; including the call instruction which only has·8 bits (0-7) for the target address. In these cases, the 9th bit (bit 8) is zeroed, and the upper three (9-11) are page bits.
Section 6.1: "The program memory is organized as 2K, 12-bit wide words.·The program memory words are addressed sequentially by a binary program counter. The program counter starts at zero. If there is no branch operation, it will increment to the maximum value possible for the device and roll over and begin again.
Internally, the program memory has a semi-transparent page structure. ·A page is composed of 512·contiguous program memory words. The lower nine bits of the program counter are zeros at the first address of a page and ones at the last address of a page. This page structure has·no·effect·on·the program counter.··The program counter will freely increment through the page boundaries."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!
James,
you are absolutely right - I had better checked the docs, or had made a test before assuming anything. In the meantime, I have run some sample code crossing a page boundary, and as you said, as long as "linear code" is executed, there is no problem. The disaster begins when you try to jump to some location outside of the page currently addressed by the program counter without having set the right page bits in the status register before.
In the end, I'm happy that I have "intuitively" programmed the right handling of this in SxSim, so there is no need to fix this "feature"
Besides this, Peter V. has pointed out some other suggestions that I have already integrated in the SxSim code. But before getting a new version out of the door, I want to finish another enhancement which might be handy - just wait and see...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
You said that calls to subroutines beyond the 1st half page can be done with the new "secret" instructions.
I haven't had the time to really try them out, can you show how you would do it ?
Bean.
http://forums.parallax.com/forums/default.aspx?f=7&m=56795&p=2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!
Smallc Compiler. This is an adapted version by Andy Yuen of the James
Hendrix SmallC 2.2 version.
The compiler itself outputs a 'M4' file which consists of pseudo-instructions
for a virtual CPU with 2 16bit accumulators and a stackpointer.
I have a bit of trouble to recompile the compiler itself but luckily an
executable is in the package.
This might be the way to get a working SCC for SX soon. All there is
needed is a makefile for the SX28. There is a 8051 port in the package.
I will try to convert that for the SX.
There are two packages: the Concurrent Small C (aug 96) and
the Retargetable Concurrrent Small C (aug 97). I also include the two
DDJ reviews for those interested.
regards peter
Post Edited By Moderator (Jon Williams) : 1/5/2005 8:49:32 PM GMT
This one I created from the 8086 one, using the 8086 registers, only
8bits wide. So even if you declare an int, you get a char. In that way
it is comparable to SX/B.
Just put the attached files with rcsc.exe and m4.exe in one dir
and run mktest.bat
That creates a viewable sasm source.
The program does not run nor does it anything useful, but it lets you
inspect the generated code for most operators.
The code is not optimal and most pcode code would better be runtime
calls to save code space. But it compiles.
If the builtin taskswitcher is usable remains to be seen.
I like some thoughts on memory access. Now direct access using bank
is supported but that requires fsr to be saved or set before accessing
memory. Accesing via a pointer that manages fsr (nothing else may)
seems about to take the same amount of cycles so I favor the latter.
regards peter
regards peter
I have optimized the macro file for SX28 to be used with rcsc.
Also optimized the 16bit runtime routines.
run mktest16.bat to create a sasm source file.
regards peter
http://www.sxlist.com/techref/language/xpl0.htm
Token interpreters like this can be very efficient: IF the tokens are chosen well. When the token invokes code that does a commonly needed, but complex task, the overhead involved in interpreting the token becomes a minor cost.
One thought: Could the pCode be loaded in an external memory (such as eeprom) as an option?
The ideal combination would be for a virtual peripheral code generator (or library of VP setups) that can work with the C code. E.g. appear as an IO device in the C code. Then you get the speed of the VP combined with the flexability of coding in C.
Best wishes and congratulations on getting this far!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!
saved in the fifo during isr, which leaves 122 bytes for user bytes + stack.
Also made all runtime labels start with a letter, so not to interfere
with names given in C source.
James, the P-codes are translated into inline code (mostly just calls
to runtime routines), sometimes working registers are loaded with
runtime values (such as return address). There is no interpreter program
running so offloading to eeprom in its present form cannot be done.
But it is possible to create a M4 file that writes a hexfile containing
the p-codes. Then 'all' you need is a pcode-interpreter. Not that simple
given the fact that references are symbolic names only. The sasm compiler
takes care of that for the inline code.
regards peter
Can you just ZIP all the files for the SmallC compiler before you upload them? It would make it much easier to download if I didn't have to manually download a bunch of individual files each time.
Thanks, PeterM
we are inside the ISR or not so there are 121 user bytes now.
Other bits in that byte will be used to simulate
enable/disable interrupt for the concurrent task keywords of RCSC.
I think there is no more problem with the unaccessible call stack.
C function calls are now performed by jumping to the function
and upon return jumping to the return address. The runtime routines
appear to require no more than four call stack levels, which means
that even when inside the ISR (function sxintrpt), there is no
problem calling other C functions as these no longer require the call stack.
(return address is on the variables stack)
regards peter
First, thanks for putting the files in a ZIP.
Second, I just glanced at the contents of the ZIP. Is this the entire project? Given how tiny the source files are, I would suggest putting the whole thing in the ZIP each time. That way, all I (or anyone else) has to do is unzip the contents and re-compile. If this is the entire project (I didn't study the contents in depth) then ignore what I just said.
Third, I'm very impressed that with the work you are putting into this. Cool stuff.
Thanks, PeterM
This now takes care of mapping port latch and direction registers
into immediate addressing instructions.
Ports RB-RE are also accessible as RBC and RDE (and !RBC and !RDE).
It is possible to define other register combinations in the macro file
(any two 8bit register combination) but for clarity I did not.
I have put all relevant files in the zip, including M4 and RCSC executable
and M4 documentation. All files go into a single directory.
Run mktest16.bat to create a sasm source from test.c
regards peter
This also reduced the runtime routines code space requirement
and increased the overall speed.
regards peter
A few suggestions / questions:
1. The "secret" instuctions could be used to implement a much more effecient call / return, no?
2. Is it true that paging issues are now avoided because the only routines that are ever actually called with the sx call instructions are the p-code?
3. Can the source code of the test program be included in the src file?
4. Would it be possible to not include the pcode routines that are not used in a given program? I have a macro that does this but it is probably best used only for larger routines such as the multiply and divide routines. (thanks for mentioning sxlist.com)
5. If is send you an advance copy of the macro tutorial I'm writing would you have time to look at it and comment? The result might help you with this project in terms of generating faster, smaller code. It will be released to sxlist supporters soon, <http://www.sxlist.com/support> but I need feedback now from people who have not worked with macros as much as I have so I can fill in what I've not explained due to assuming falsely that people know it already.
Anyway, COOL and keep up the great work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
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!