The Propeller and <stdio.h>
LoopyByteloose
Posts: 12,537
Well, I have been working with the SimpleText.h (v.98) library and when I refer to the SimpleTools documentation for it (v.98), I see that it supposedly includes the <stdio.h>.
Can I presume that ALL of the STDIO library is included, or is there some place that documents which parts are not included?
The language for the Propeller GCC says that it attempts to comply with ANSI C. I'd just prefer to know if it succeeds in doing so.
It does seem that the SimpleText and Serial libaries are not supporting the STDIO. Not sure what is going on.
Can I presume that ALL of the STDIO library is included, or is there some place that documents which parts are not included?
The language for the Propeller GCC says that it attempts to comply with ANSI C. I'd just prefer to know if it succeeds in doing so.
It does seem that the SimpleText and Serial libaries are not supporting the STDIO. Not sure what is going on.
Comments
The Propeller GCC standard library functions and usage are ANSI C compliant. They come mostly from the BSD Unix library.
Supporting all stdio.h features for simpletext.h print() and friends would make them unnecessarily big. If you want ANSI C printing, use printf() which is ANSI C compliant.
I do understand that including all and everything in the ANSI C library is not feasible or useful. But I don't understand what is and what isn't.
Just not using the same names doesn't make it clear to new users what is going on. The Propeller GCC Google site does indeed claim that it attempts to comply with ANSI C. A clear declaration of non-standard alternatives and additions being offer would be helpful.
(A ways back we went through a huge debate about ANSI Forth versus non-ANSI Forth and it came down to the same thing... when it is non-standard, tell us in detail. People are trying to apply tutorials and texts from elsewhere and from long ago.)
ANSI C is both the C language and the ANSI C libraries.
Fortunately, The C Programing Language:2ed by Kernighan and Riche, 1988 specifically avoids going very far into the ANSI C libraries. And STDIO seems to predominately use Getchr(), Putchr(), and Printf() to and from STDIN and STDOUT.
I think you are safe with that being used as a tutorial, if someone would just clarify that Debug is equivalent to STDIN and STDOUT. Debug port and Terminal seem to be the same thing, but I am guessing that Debug represents Pin 30 and Pin 31 serial and Terminal represents a broader idea of some sort. For the most part, they seem to be the same thing.. but a bit confusing.
It seems that Propeller GCC is trying to avoid using the terms STDIN, STDOUT, and STDERR -- but these are ubiquitous to C tutorials everywhere. It would be wise to point out what and where replacements can be had. STDIN and STDOUT are often keyboard and monitor respectively. If that is not currently available, a clarification would be nice.
As you can see.. this makes it a bit awkward for me to understand, but I have had to presume that STDIN and STDOUT are equal to the Debug port, and that there is no STDERR feature.
Is that all correct? I don't see why SimpleTools library documentation makes reference to STDIO.h in the lines of #include .....
In sum, don't make new users guess a lot.. I suspect they will just give up and look for something else.
I think the reason that the SimpleTools text library exists is because the C standard I/O uses a lot of memory and the I/O is buffered by default. Standard I/O can be used in an unbuffered manner, but the method for doing this requires intimate knowledge of standard I/O.
If you want to use the SimpleTools library you should follow the tutorials on how to use it. Or you can completely ignore SimpleTools and just use the standard ANSI libraries. There's a wealth of information on the internet for writing C code using stdio.
I think most examples from K&R or similar books should compile and run "as is" with PropGCC, although to do disk I/O with an SD card may require some tweaking.
A. I grasp the concept of what SimpleTools and SimpleText libraries are try to do. And I accept that there will be parts of ANSI C that will not be supported. (We went down this road with the discussion of ANSI Forth compliance, so I really don't want to revisit all that.) Nothing wrong with saving memory for other things, but that aspect is not very well explained at this point.
What I am saying and have previously said is that when the Propeller GCC provides non-standard features, please clarify what they are and give some idea of how they are intended to replace standard features. Of course, point out how memory resources are conserved by doing so.... (avoiding floating point seems to save kilobytes of hubram).
B. Suggestions of reading the source code are quite absurd for the beginner.
If one is just starting out learning C, how are they supposed to weigh into source code that is in C?? And some GCC might even be in C++??
I am still not very comfortable with reading source code in anything -- PASM or GCC. But I do try and I do see that it does enhance my ability to learn more.
C. If you want Propeller GCC to be popular, don't presume your audience knows much. Do presume your audience with download texts and tutorials from the internet that free and readily available.
So it would be very helpful to bridge the gap about STDIO and Debug/Terminal. We all know that the serial port is likely the most heavily used portion of C code. It deserves focused support, and not presuming everyone will be coming from Spin. It you thing about it, there are a lot of PBASIC users that gave up on SPIN that might try migrating to GCC. And there are the Arduino users that might desire to migrate to the Propeller.
D. There seems to be a tendency from some in the SimpleIDE community to interpret 'simple' as a minimalist approach to everything -- the IDE, the documentation, and the libraries. That just might make it all rather cryptic to the general public.
E. Why bother will all this? Well, people have been told for decades that C is all about portability. They are going to expect that C code on the Propeller can be ported without too much effort. This will become even more expected with the Propeller2 and its added RAM and speed resources.
About STDIO
You seem to say it is available in Propeller C as an alternative, but I don't see how it is tied into Serial.h.
If I compile code with the inclusion of its libary, will it compile? And if it does compile, will it work?
I can run some tests to try to answer these questions myself. But I have already spent a few weeks trying to sort out this as my download of SimpleIDE documentation for SimpleText was v.85.
I finally got v.98 which is much better, but am in a muddle with #include <stdio.h>
About K&R
Well I suspect that the 'printf()' of K&R might have to use the 'print()' from SimpleText as a replacement in order to do without the <stdio.h>.
I guess you are saying that I should survey the whole of K&R for what will and will not work. With a pdf copy and a FIND function, that may be not too hard to do.
I would suggest that you try compiling and running sample programs on your Linux box first. You should then be able to do the same using PropGCC. Try using stdin, stdout and stderr with functions like fscanf(stdin, ...) and fprintf(stdout, ...) or fprintf(stderr, ...). You will see on a Linux box that you can do something like "myprogram >tempfile", and writes to stdout will go into tempfile. Writes to stderr will still appear on the console.
Try running a program where the main program is defined as "main(int argc, char *argv[])" on a Linux box. You'll see that argc indicates the number of command-line parameters and argv is a list of string pointers that point to the null-terminated command-line parameters. Try writing an echo program that just prints out the command-line parameters.
Using PropGCC you won't be able to try out the command-line parameter feature or file redirection since this is an OS feature. spinix does provide support for this, but I would suggest getting up to speed on C using Linux before you would try doing this under spinix.
Ray
Sure I can just study STDIO on Linux, but I need to sort out the serial port and its related buffer on the Propeller in C. I am still trying to work out a CNC g-code interpreter in C on the Propeller.
About all I can conclude from this is that GETCHR() and PUTCHR() are the same in SimpleText and if I stay away from PRINT() and SCAN(), I may be able to get everything done in a smaller amount of HubRAM... just maybe.
++++++++++++
My main point was in hopes of raising awareness that new users are getting hung up with the Serial i/o being different from other forms of C that they are coming from.
If one cannot not get the equivalent of a STDIN and STDOUT quickly set up, the new user is likely going to feel that the Propeller is not for them. I just plead to everyone to NOT make that occur.
#include <stdio.h>
int main(void)
{
int ch = getchar();
printf("Hello World.\n");
printf("Got character [%d] '%c'\n", ch, ch);
return 0;
}
[/php]
Done. What's so hard about that?
Most C programmers know how to do that. Interview questions are harder LOL.
Thanks. I will try that instead of SimpleText.
+++++++++++++++++++
Actually I am more confused and concerned by how Scanf() works on the Propeller and how it interacts with floating point. K&R has a whole chapter at the end, Chapter 7 and I need to study that.
In any event, I have simply accepted that I should stop lobbying for the 'rank beginner' and just figure out how to do these things for myself. The more time I stay away from the Forum and actually read K&R, the sooner I might understand this stuff.
Thanks for the suggestions.
I still am being driven by a long-term goal of porting CNC over to the Propeller from Arduino. But I just don't want to bore youall to tears with a blow by blow blog of every little discovery I am making. I am likely making this all harder for me by going back and forth between Arduino code, OpenAVR code, GCC, C++, and C.
Here is how the AVR people explain their non-ANSI standard stdio.h file. I think it actually shows a lot of panache. Something with a similar level of clarity could be useful for the Propeller. It is worth reading the whole avr/stdio.h to see how they worked out GCC in the confines of a micro-controller.
"
Introduction to the Standard IO facilities
This file declares the standard IO facilities that are implemented
in \c avr-libc. Due to the nature of the underlying hardware,
only a limited subset of standard IO is implemented. There is no
actual file implementation available, so only device IO can be
performed. Since there's no operating system, the application
needs to provide enough details about their devices in order to
make them usable by the standard IO facilities.
Due to space constraints, some functionality has not been
implemented at all (like some of the \c printf conversions that
have been left out). Nevertheless, potential users of this
implementation should be warned: the \c printf and \c scanf families of functions, although
usually associated with presumably simple things like the
famous "Hello, world!" program, are actually fairly complex
which causes their inclusion to eat up a fair amount of code space.
Also, they are not fast due to the nature of interpreting the
format string at run-time. Whenever possible, resorting to the
(sometimes non-standard) predetermined conversion facilities that are
offered by avr-libc will usually cost much less in terms of speed
and code size."
and it goes on with quite a bit more detail about AVR's particular work arounds.
There is more useful and somewhat surprising info about STDIN, STDOUT, and STDERR. And it makes good sense.
+++++++++++
I am NOT saying that Parallax should follow their lead on an item by item basis. But the material may show some details overlooked or items that might be done better.
It is all there and useful. It is the kind of documentation that is really helpful to a user that is approaching learning from a traditional ANSI C tutorial.
An AVR is a type of micro-controller made by the ATMEL corporation.
ATMEL are the AVR people but does not make avrlibc.
avrlibc is an open source project currently maintained by: Marek Michalkiewicz, Joerg Wunsch, Eric Weddington, Anatoly Sokolov, Dmitry Xmelkov and a cast of thousands.
I'm pretty sure everything you mention there is catered for by propgcc.
There is only one Prop with a small number of memory models, so I don't think it requires as much documentation. There is some very useful information at https://code.google.com/p/propgcc/w/list . The PropGCC demos directory provide several useful demo programs that can guide novice and experience users. The SimpleIDE Learn tutorials and sample programs should help programmers implement almost anything they want in PropGCC. Eric's spin2cpp utility allows you to port almost any Spin Object from the OBEX to C or C++. The fantastic Parallax forum provides access to experienced programmers that can answer questions and provide guidance.
Loopy, I can't imagine how you could get any more support on learning to program the Prop in C.
In particular, the excerpt I listed above made clear the printf() and scanf() and all the file system related items were problems for microcontrollers.
The same file goes on to explain that STDIN, STDOUT, and STDERR are not active by default as nobody can anticipate what would be the default setting in a microcontroller.
The other standard libraries might be very conforming to ANSI C and not worth reading the notation.
Here is what I have been looking at. And the AVR people are merely reference to the authors. Look like only one in this case. Joerg Wunsch.
++++++++++
The questions I had about these items may not be raised by other learners. It was just nice to see that what the AVR deals with are the same as what the Propeller does. And the solutions are quite similar.