SX/C Documentation and Code Examples for your Review
Ken Gracey
Posts: 7,401
Hello SX users,
Below you will find documenation and code examples from CCS for the SX/C compiler. The documentation is fairly dated, as this product had been available in the past. Please post all of your ideas, complaints, questions and input on this thread. I'm tracking your requests individually and will see that they are dealt with through compiler improvements, documentation modifications, or omitted with reason. You won't be able to have every feature you want for $99.
Right away I notice that the compiler could employ more SX architecture-specific features. Keep the SX's design in mind as you make comments. Any input is welcome.
Sincerely,
Ken Gracey
Parallax, Inc.
Below you will find documenation and code examples from CCS for the SX/C compiler. The documentation is fairly dated, as this product had been available in the past. Please post all of your ideas, complaints, questions and input on this thread. I'm tracking your requests individually and will see that they are dealt with through compiler improvements, documentation modifications, or omitted with reason. You won't be able to have every feature you want for $99.
Right away I notice that the compiler could employ more SX architecture-specific features. Keep the SX's design in mind as you make comments. Any input is welcome.
Sincerely,
Ken Gracey
Parallax, Inc.
Comments
For anyone just starting out with C, please ignore my suggestion of reading a book on C++.
It is a quite different kind of C and intended more for desktop computers and larger systems.
As usual, Parallax will help you get the basics first, then you can move on to the bigger and better.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
I peeked at the docs download and note that it is dated September 2002. So I expect it to be the same root compiler as I have already used from CCS. Could you please briefly describe the major differences between what you anticipate delivering under the Parallax banner vs the standard offering that the documentation pertains to. I had thought you said earlier that this was going to be an "SX specific" compiler, not some second rate re-hash of the PIC complier.
If the roots of this thing are still deeply in PIC territory, then I expect you are opening up a real can of worms working with this product; it was a REAL pile of Smile in my opinion. If, on the other hand it is significantly different, then the situation might be much better.
I truly am hoping for the best....its just that I've been very disappointed.
Cheers,
Peter (pjv)
I'm not sure of the best way to present comments. I suppose each contributor could make their own page, and add to it at will with "post-edits", thus building an ever changing page, or just make individual posts of sort comments; but you mights get an unwieldy number of them. I'll start with the second approach.
Please delete all documentation references and code "include" references to ATD (Advance Trans Data) tools; they have no place in an SX specific compiler.
Please delete all non SX processor references in the code examples; that just confuses things.
Please delete, or at least "soften", the offensive copyright warnings at the top of each example.
Please give a brief description of the purpose of each sample code.
Please COMMENT the examples, otherwise beginners in C like me will need to spend an inordinate amount of time figuring out what is happening. It's the worst I've ever seen.
Please test every example (cleaned-up) to confirm it compiles; my experience with this was dismal.... they had obviously NOT tested them.....lots of "out of memory" errors with no qualified proposed fixes.
Please recompile the "in-line assembler" portions in the examples to reflect SX mnemonics rather than PIC mnemonics......very confusing.
More to follow (LOTS of it) when I get more time.
Cheers,
Peter (pjv)
Post Edited (pjv) : 12/13/2005 5:24:20 PM GMT
The reason we're looking at a C compiler for the SX is due to·frequent customer requests.·Parallax has little internal resources to put into·the compiler features at this moment, so I'm relying largely on our customer input to make this product functional.·If we applied our internal resources (other than SX-Key IDE integration and some code examples) it would be at the expense of another new product [noparse][[/noparse]which I think you would like to have from us much more than this one].
Many of our products have been created with customer direction,·both hardware and software.·I'm viewing this mostly as a management project from our end. Whatever issues·or improvements are presented will be communicated to CCS and together we'll determine how to address them. The goal is an SX-specific compiler using C.
Like you, I don't want any PIC-specific features in this compiler. This compiler must be targeted at the SX to be useful to our customers.
And for these reasons, I've asked our customers to make comment on·the current version of this compiler. I'm keeping track of these issues and·dealing with them one at a time with CCS. Our other goal is to have smooth integration with the SX-Key and source-level debug.
Therefore, I've asked that comments of any type be posted on this thread (I'll make it sticky at some point, but I'm a bit hesitant to do that because some "sticky" information·dies off too quickly).
If you think my approach is flawed, let me know. So far I truly appreciate the effort you've given the documentation. That's what I was hoping for.
Sincerely,
Ken Gracey
Parallax, Inc.
Pleased to help where I can.
So, let me understand;
At this point in time there is NOT a new, SX specific version of the CCS compiler being written? What you are doing is soliciting input from users, and communicating your as well as your clients' wishes to CCS, and trusting them to implement those wishes/changes, and at the end of that process have a compiler, still based on its PIC roots, that is more suitable to SXes than the current standard CCS offering.........
If this is the case, then I think you are in for a long and troublesome journey. I can't see how that poor a product can be upgraded to be what it should and needs to be without a TOTAL rewrite, keeping the SX's specific bank and page architecture at the focus. This is something that is NOT done in the standard offering; just a bunch of ill-conceived work-arounds.
My opinion again........but this product is NOT usable in any practical terms.
To gain my interest, which is significant, I'm expecting you to have them "start from scratch".
Sincerely,
Peter (pjv)
Yes, that's right. If the work-arounds are not removed and the compiler isn't improved, you'll never have a chance to buy it. Whether or not they "start from scratch" I don't know and I can't control, but I will certainly encourage. I'm committed to seeing the issues through to resolution, as long as we've got some support from customers and CCS. I think it's too early to draw conclusions about what quality of compiler will be available to our SX customers until CCS has had the opportunity to consider input.
Ken Gracey
Parallax, Inc.
Four of the six resources I listed are freely available via website or download.
I took a look at the sample code and PDF file. I think some of the examples are dated (the Motorola EPROMs are an example). I would like to see some improvement on the optimizer, specifically optimizing for the SX. The manual should be updated to 2005 or 2006 instead of 2002. Two areas I think would be very benefical are 1) interrupt support, and 2) Virtual Periperal Template. The CCS interrupt support has always been resonable for the PIC but I don't know how well it works with the SX interrupt architecture. Even if not in the original release a sample ocde template for virtual periperals would be benefical, even if only as an example on how VP works.
Oliver
1. The PCW/SC Overview section should be expanded to give a broader overview of C, and a detailed description of the differences between SXC and ANSI C. Everything that would work in ANSI C, but not in SXC, should be clearly annotated in a central, easy to find location. This should be done in two parts: a) What was omitted from ANSI C, b) What was added beyond ANSI C.
2. There is very little information about the IDE and programming environment.
3. There are no graphics of the IDE.
4. The installation and configuration instructions could be expanded.
5. There is no description of the overall development process, and what the different pieces are.
6. Add the following tables: all reserved words, all available escape sequences, value ranges for number types, ASCII character chart 0-127.
7. Anything listed as "not permitted" in a function description should be called out as a note. It makes exceptions easier to spot when scanning the text.
8. There should be a listing and descriptions of all available libraries, both standard C and proprietary. If the standard libraries differ from ANSI C, it should be clearly explained how they differ. Each library description should include a list of available functions.
9. Functions should be listed alphabetically by library. They are currently listed alphabetically with no separation by library.
Overall, the manual looks like it is targeted at experienced developers. Some sections, such as the installation procedures, are hit or miss: if you know how to install software, the brevity won't bother you. But there is no additional information on configuration, system requirements, etc.
Other items that should be considered:
1. Adding SX architecture info, basic descriptions, etc.
2. Adding more info on assembly language
3. Moving the sample descriptions to a seperate readme document
4. Adding SX-Key instructions
I suspect that when you try to bring your PIC experiences to the SX, you will find that you are carrying a lot of 'extra baggage'.
Most of these problems are related to PICs approach to the marketplace.
PIC requires vast compiler support for an array of hardware specific versions.
It puts the producer of a compiler in the difficult position of just keeping up their database of adaptations.
The SX-Ubicom line only has a few products to support and basically only two catagories of devices that require 'personalized configuration'.
The SX-18/20/28 and the SX-48/52.
Above, Kevin Wood is offering good suggestion about improving the communication of 'need-to-know' and 'nice-to-know' information
Unlike PIC - The compiler doesn't have to be all things to many different kinds of device users.
It is a much easier job for the people that are maintaining the compiler and allows them to put their resources into excellence in the compiler's basic functionality.
The compiler does not have to be constantly updated for new hardware.
Of course, the one major difference is that the compiler must be adapted to fully deploy the Interupt Service Routine and allow for the use of Virtual Peripherals.
As far as adapting the CCS PIC compiler to SX, there are only 4 additional mneumonic program commands to add. Admittedly these are related to hardware differences between the PIC and the SX, but the good news is that mostly are related to having more programing EEPROM and RAM.
I suspect that anyone programing in C might find using the SX-Ubicom easier to navigate than the PIC which is overrun with special needs of each particular microprocessor.
In assembler, the PIC provides the hardware to allow less informed programers to make due. They don't have to understand UARTS and other serial interfaces.
If you really don't want to understand those things, I suspect CCS will be providing a selection of 'objects' to insert.
And this may be what we are really waiting on: the UART, th SPI, the One-wire, the I2C, and the LCD objects.
Alteratively SX/B is coming along rapidly and allows you to get the code running in Basic and then you can look at the Assembly file to learn more via 'reverse engineering'
Both C [noparse][[/noparse]via C+, and C++] and MicroSoft's VisualBasic have historically evolved further and further away from the low-level architecture. I cannot get any feel for what is happening as a low level. Parallax has evolved educationally in the opposite direction toward teach people exactly how much control can be generated from a few bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Also the workarounds and limitations should be removed.
I mean, short int for bit type and no pointer to constant array, that is ugly.
My proposal:
types:
bit············ - 1 bit
char·········· - unsigned byte
signed char· - signed byte
int············· - 2 bytes
unsigned int· - 2 bytes
pointer········ - 2 bytes
long·int········ - 4 bytes
unsigned long·int - 4 bytes
float············ - 4 bytes
A pointer should be 16bits, allowing for·accessing structures and unions stored in ROM as well
as access to RAM. One could virtually place the ram addresses after the rom addresses.
Bit arrays should be allowed in ram, as should pointers to bit arrays.
0x0000··········· = null pointer
0x4000-0x40FF = RAM·bytes in banks································ test b14
0x2000-0x37FF = ROM packed (aliases with rom) see below··· test b13
0x1000-0x1FFF = ROM·····················································test b12
0x8800-0x880F = global RAM············································ test b11
0x8000-0x87FF = RAM bit arrays (aliases with ram banks)·······test b15
As access through pointer is indirect, the above values allow direct jump into correct code
to handle the different storage areas, by testing bits 11 to 15 of the address.
Use of·the address operator &·hides all this from the user.
Perhaps a short pointer type·that is just 8 bits (for ram access, but SX48 has more than 256 bytes ram).
I think the compiler should support constant packed arrays (1.5 bytes stored in ROM word) to maximize
rom storage. I would like to be able to use
Define reserved word 'packed'
const packed char[noparse]/noparse data = {"some text",'a','b',int 0x0024, long 0x12345678};
and the compiler fills in the rom words, using the necessary number of rom words.
char/int/long/float packed·*p; //pointer to packed rom
When accessing packed rom the compiler assembles result including highest 4 bits of rom words.
char/int/long/float *p; //pointer to ram/rom
When accessing·rom the compiler assembles result ignoring the·highest 4 bits of rom words.
regards peter
Post Edited (Peter Verkaik) : 12/14/2005 3:28:21 PM GMT