Shop OBEX P1 Docs P2 Docs Learn Events
Catalina 3.4 - Page 5 — Parallax Forums

Catalina 3.4

1235711

Comments

  • RossHRossH Posts: 5,512
    edited 2011-11-05 18:31
    David Betz wrote: »
    Ummm... for various reasons this version of Basic uses printf not print. So a program to count from 1 to 10 would look like this:

    100 for x=1 to 10
    110 printf("%d\n", x)
    120 next x

    I would change this to the more traditional "print" but I'm not sure this version of basic is likely to be used. It was more of a proof-of-concept that I could get the compiler running on small MCUs like the PIC24 and the Atmega328p. I chose this version to port to the Propeller because I was hoping it would fit in LMM mode (your TINY memory model) but it's still too big.

    Yes, by quite a long way. It would easily run on the Prop 2 in TINY mode though :)

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-05 19:04
    The download of xbasic is now working but how do I open a terminal window using Code::Blocks so I can interact with the program?
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-05 19:54
    I just tried using Hyperterminal and I'm getting very weird results. First, it seems the RETURN key generates a linefeed. Second, I get strange characters as well as the ones I'm printing myself.

    For example, this program prints the following results:
    100 printf("Hello")
    110 printf("Goodbye\n")
    
    HVHVHVHVHVHelloGoodbye
    

    Any idea why this might be happening?
  • RossHRossH Posts: 5,512
    edited 2011-11-05 20:38
    David Betz wrote: »
    I just tried using Hyperterminal and I'm getting very weird results. First, it seems the RETURN key generates a linefeed. Second, I get strange characters as well as the ones I'm printing myself.

    For example, this program prints the following results:
    100 printf("Hello")
    110 printf("Goodbye\n")
    
    HVHVHVHVHVHelloGoodbye
    

    Any idea why this might be happening?

    I don't have hyperterminal - maybe it has a problem. Using putty (or PST) I get:
    list
    10 printf("hello")
    20 printf("goodbye\n")
    OK
    run
    H:228 O:3 D:48 V:0 T:54
    hellogoodbye
    OK
    

    Note that if your terminal emularor needs an explicit CR along with each LF as a terminator on the output stream then you can enable the CR_ON_LF option. PST in particular is not very configurable, so I had to add that as a option along with NO_CR_TO_LF (if you want your program to see a CR instead of LF as a terminator on the input stream). All this is strictly non-ANSI standard behaviour, but unfortunately necessary under Windows unless you are using an ANSI standard terminal emulator (e.g. putty).

    Ross.
  • RossHRossH Posts: 5,512
    edited 2011-11-05 20:39
    David Betz wrote: »
    The download of xbasic is now working but how do I open a terminal window using Code::Blocks so I can interact with the program?

    Just use putty or PST. I didn't put a specific option on the Tools menu to start a terminal emulator since I don't know what terminal emulator people will be using.

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-05 20:51
    I just tried PST and I'm still having trouble. I suspect I still have some configuration option wrong. I'll go back and look again.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-05 20:55
    David Betz wrote: »
    I just tried PST and I'm still having trouble. I suspect I still have some configuration option wrong. I'll go back and look again.
    Here are the options I have set. They are all set in the "xbasic" tab. Nothing is set in the "Release" tab. I assume that means it will inherit all settings from the "xbasic" tab.
    C3
    libci
    SMALL
    8K Cache
    FLASH
    PC
    

    Do I need anything else?
  • RossHRossH Posts: 5,512
    edited 2011-11-05 21:34
    David Betz wrote: »
    Here are the options I have set. They are all set in the "xbasic" tab. Nothing is set in the "Release" tab. I assume that means it will inherit all settings from the "xbasic" tab.
    C3
    libci
    SMALL
    8K Cache
    FLASH
    PC
    

    Do I need anything else?

    Aha! I built it with libcx and it works. If I build with libc or libci I see (approximately) what you see. That is very odd. Does your program make any assumptions about the way the I/O subsystem works, or try to mess about with internal data structures?

    Ross.
  • RossHRossH Posts: 5,512
    edited 2011-11-05 22:28
    Hi David,

    I see the problem. Your program uses vsprintf, which depends on the streams infrastructure, which is not inlcuded when using the simplified libc or libci libraries - these libraries only include support for the three predefined streams stdin, stdout and stderr. Support for other streams is only included in the full libcx library (or libcix).

    This would affect sprintf as well - I don't think there's much I can do about this in the short term, except document it as an unexpected limitation of using libc or libci. For the moment, if you need vsprintf or sprintf you will need to compile with either the libcx or libcix libraries.

    I'll see if I can include a fixed version in 3.5.

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 04:01
    RossH wrote: »
    Hi David,

    I see the problem. Your program uses vsprintf, which depends on the streams infrastructure, which is not inlcuded when using the simplified libc or libci libraries - these libraries only include support for the three predefined streams stdin, stdout and stderr. Support for other streams is only included in the full libcx library (or libcix).

    This would affect sprintf as well - I don't think there's much I can do about this in the short term, except document it as an unexpected limitation of using libc or libci. For the moment, if you need vsprintf or sprintf you will need to compile with either the libcx or libcix libraries.

    I'll see if I can include a fixed version in 3.5.

    Ross.
    Switching to libcix worked for me. Thanks for pointing that out. I notice I'm getting a bunch of warnings when I compile xbasic that I think shouldn't be there. Doesn't ANSI C allow NULL (which is defined as a void*) to be assigned to any pointer value? I shouldn't have to case NULL to assign it to some other type of pointer should I?
    ..\db_generate.c|42|warning: conversion from `pointer to void' to `pointer to void function(pointer to ParseContext,PValOp,pointer to struct PVAL)' is compiler dependent|
    

    Here is the code in question:
    typedef struct PVAL PVAL;
    struct PVAL {
        void (*fcn)(ParseContext *c, PValOp op, PVAL *pv);
        union {
            String *str;
            int val;
        } u;
    };
    
    ...
    
        PVAL *pv;
    
    ...
    
        pv->fcn = NULL;
    
  • RossHRossH Posts: 5,512
    edited 2011-11-06 14:13
    David Betz wrote: »
    Doesn't ANSI C allow NULL (which is defined as a void*) to be assigned to any pointer value? I shouldn't have to case NULL to assign it to some other type of pointer should I?

    Pointers to functions are not guaranteed to be the same as data pointers, and NULL is a data pointer. This is specifically discussed in the ANSI C standard (in the "Common Extensions" section - specifically, the section titled "Function pointer casts").

    The general description of all such extensions is:
    The following extensions are widely used in many systems, but are not portable to all implementations. The inclusion of any extension that may cause a strictly conforming program to become invalid renders an implementation nonconforming. Examples of such extensions are new keywords, extra library functions declared in standard headers, or predefined macros with names that do not begin with an underscore.

    So a warning that this is implementation-specific is appropriate (if perhaps a little over-zealous!). In the particular case of LCC/Catalina this extension is supported, but when porting the same code to other compilers it may not be.

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 14:24
    RossH wrote: »
    Pointers to functions are not guaranteed to be the same as data pointers, and NULL is a data pointer. This is specifically discussed in the ANSI C standard (in the "Common Extensions" section - specifically, the section titled "Function pointer casts").

    The general description of all such extensions is:



    So a warning that this is implementation-specific is appropriate (if perhaps a little over-zealous!). In the particular case of LCC/Catalina this extension is supported, but when porting the same code to other compilers it may not be.

    Ross.
    So what is the equivilent NULL function pointer? Maybe NULL should simply be defined as 0 rather than (void *)0. I've never gotten this warning in anything other than Catalina and I've used *lots* of different C compilers. Maybe this warning should be off by default and enabled by a command line option.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 14:28
    David Betz wrote: »
    So what is the equivilent NULL function pointer? Maybe NULL should simply be defined as 0 rather than (void *)0. I've never gotten this warning in anything other than Catalina and I've used *lots* of different C compilers. Maybe this warning should be off by default and enabled by a command line option.

    Here is how NULL is defined in the simple library we built for GCC:
    #ifndef NULL
    #define NULL (0)
    #endif
    
  • RossHRossH Posts: 5,512
    edited 2011-11-06 14:49
    David Betz wrote: »
    So what is the equivilent NULL function pointer? Maybe NULL should simply be defined as 0 rather than (void *)0. I've never gotten this warning in anything other than Catalina and I've used *lots* of different C compilers. Maybe this warning should be off by default and enabled by a command line option.

    Catalina supports this particular extension, so a NULL function pointer is the same as a NULL data pointer (which is after all just an agreed value that tells you the pointer doesn't currently point to anything).

    I agree LCC can be a bit over-zealous about its warnings (the one that always worries me is when it tells you it has "elided" some of your code!). You can disable warning like this using the "Suppress all warnings" option (-W-w).

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 14:51
    RossH wrote: »
    Catalina supports this particular extension, so a NULL function pointer is the same as a NULL data pointer (which is after all just an agreed value that tells you the pointer doesn't currently point to anything).

    I agree LCC can be a bit over-zealous about its warnings (the one that always worries me is when it tells you it has "elided" some of your code!). You can disable warning like this using the "Suppress all warnings" option (-W-w).

    Ross.
    I don't believe in disabling warnings. They can be very useful in finding errors in the code. That is why it is important that you don't get extraneous warnings.

    FYI, newlib also defines NULL as 0 with no cast.
  • RossHRossH Posts: 5,512
    edited 2011-11-06 15:31
    David Betz wrote: »
    I don't believe in disabling warnings. They can be very useful in finding errors in the code. That is why it is important that you don't get extraneous warnings.

    FYI, newlib also defines NULL as 0 with no cast.

    Either 0 or (void *)0 is acceptable as the definition of NULL. The latter has some advantages - specifically that it does generate more warnings about potentially non-portable code.

    There is a (very extensive!) discussion of NULL here - who knew there was so much to know about nothing?

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 17:47
    RossH wrote: »
    Either 0 or (void *)0 is acceptable as the definition of NULL. The latter has some advantages - specifically that it does generate more warnings about potentially non-portable code.

    There is a (very extensive!) discussion of NULL here - who knew there was so much to know about nothing?

    Ross.
    Since I believe the ANSI standard says that any pointer can be assigned the value zero it seems like it would be best for NULL to just be zero. That eliminates the need for zillions of different NULL-like values for each possible pointer type. It is also clearer to assign NULL to a pointer variable than the constant zero.
  • RossHRossH Posts: 5,512
    edited 2011-11-06 18:03
    David Betz wrote: »
    Since I believe the ANSI standard says that any pointer can be assigned the value zero it seems like it would be best for NULL to just be zero. That eliminates the need for zillions of different NULL-like values for each possible pointer type. It is also clearer to assign NULL to a pointer variable than the constant zero.

    This is explicitly addressed in the reference I posted as question 5.16:
    Q: Given all the confusion surrounding null pointers, wouldn't it be easier simply to require them to be represented internally by zeroes?A: Some implementations naturally represent null pointers by special, nonzero bit patterns, particularly when it can be arranged that inadvertently using those values triggers automatic hardware traps. Requiring null pointers to be represented internally as 0, and therefore disallowing use of the special, nonzero values, would be an unfortunate step backwards, because catching errors which result in invalid accesses is a Good Thing.
    Besides, what would such a requirement really accomplish? Proper understanding of null pointers does not require knowledge of the internal representation, whether zero or nonzero. Assuming that null pointers are internally zero does not make any code easier to write (except for a certain ill-advised usage of calloc; see question 7.31). Known-zero internal pointers would not reduce the need for casts in function calls, because the size of the pointer might still be different from that of an int. (If ``nil'' were used to request null pointers, as mentioned in question 5.14, the urge to assume an internal zero representation would not even arise.)
    Ross.
  • RossHRossH Posts: 5,512
    edited 2011-11-06 18:54
    David Betz wrote: »
    I wish you luck with Catalina. I won't be using it anymore myself. I find that it diverges from standard practice enough that it is unpleasant to use and that any requests to make it conform more closely invariably result in obscure references to standards documents rather than an effort to make the tool more useful. Others of course enjoy Catalina and I wish them well with it.

    Hi David,

    Wow! I guess it is not too hard for anyone to read between the lines here. But for my part I wish you more success in your future endeavors.

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 19:01
    RossH wrote: »
    Hi David,

    Wow! I guess it is not too hard for anyone to read between the lines here. But for my part I wish you more success in your future endeavors.

    Ross.
    There is nothing between the lines. I started working with Catalina long before there was any GCC project and had similar problems then. This isn't an attempt to promote any other solution but more a frustration with working with something I'm not comfortable with and which seems rigid and unwilling to conform to common practice. I acknowledge that it is liked by many people and I am happy for them that it satisfies their needs. I guess it's me that is the problem.
  • RossHRossH Posts: 5,512
    edited 2011-11-06 19:31
    David Betz wrote: »
    There is nothing between the lines. I started working with Catalina long before there was any GCC project and had similar problems then. This isn't an attempt to promote any other solution but more a frustration with working with something I'm not comfortable with and which seems rigid and unwilling to conform to common practice. I acknowledge that it is liked by many people and I am happy for them that it satisfies their needs. I guess it's me that is the problem.

    Yes, I can see how the fact that Catalina successfully compiles and runs your xbasic program on the Propeller could easily be outweighed by the fact that you have to specify -W-D to define a symbol on the command line instead of -D, and that Catalina throws a warning message about xbasic using compiler dependent language features.

    Your decision, of course - but again I just have to say ... Wow!

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 19:38
    RossH wrote: »
    Yes, I can see how the fact that Catalina successfully compiles and runs your xbasic program on the Propeller could easily be outweighed by the fact that you have to specify -W-D to define a symbol on the command line instead of -D, and that Catalina throws a warning message about xbasic using compiler dependent language features.

    Your decision, of course - but again I just have to say ... Wow!

    Ross.
    Yes, it does run my xbasic proof-of-concept program. It is very slow at downloading it though. We've discussed this before I think but I may have an option to offer you now. I have a loader that I think can be made to download Catalina programs faster than payload. I know you prefer to use an SD card and catalyst but some of your users might like a faster serial loader. If so, I'd be happy to work with you to adapt my loader so that it can handle Catalina executables. It can currently handle ELF and Spin Binary files but I could extend it to support Catalina binaries as well. Of course I'm mostly talking about XMM executables since we both use the standard Propeller loader protocol for programs that fit in hub memory.
  • RossHRossH Posts: 5,512
    edited 2011-11-06 19:53
    David Betz wrote: »
    Yes, it does run my xbasic proof-of-concept program. It is very slow at downloading it though.

    Oops - should have added this one to the list as well, since it seems to be a biggie with both you and Jazzed. But I do appreciate the offer. Post your code and I'll have a look at it.

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 19:56
    RossH wrote: »
    Hi David,

    Wow! I guess it is not too hard for anyone to read between the lines here. But for my part I wish you more success in your future endeavors.

    Ross.

    One more comment on your reply. You may have noticed that I deleted the message to which your reply was written. I did this before your reply appeared but apparently you had started writing the reply before I finished the delete. I deleted it because I thought better of it and decided it was a bit rash and probably not what I really intend to do but more a reaction to being overtired. I shouldn't post messages when in this state. Sorry!
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-06 19:58
    RossH wrote: »
    Oops - should have added this one to the list as well, since it seems to be a biggie with both you and Jazzed. But I do appreciate the offer. Post your code and I'll have a look at it.

    Ross.

    The code is on Google Code in the "propgcc" project under the "loader" directory. But, it might be easier if I just collect the information I need from you about your executable file format and add it myself. I'm afraid that the code may not be that easy to navigate. :-(
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-11-06 20:07
    Yes, it does run my xbasic proof-of-concept program. It is very slow at downloading it though. We've discussed this before I think but I may have an option to offer you now. I have a loader that I think can be made to download Catalina programs faster than payload.

    I did some speed tests and I seem to recall payload was about as fast as it goes. 115k which is about 11 kilobytes a second (8 data bits, one stop bit, one start bit = 10 bits per 'byte' so the number of bytes per second is about 1/10th of the baud rate). If you have a 200 kilobyte program it is going to take nearly 20 seconds. Some of my Catalina programs have grown to 300kilobytes.

    I looked at faster baud rates but there seem to be limitations coming up - eg within vb.net, within some usb to serial drivers. Some terminal programs max out at 57k. So pushing the baud rate up is difficult.

    I have this idea (I even have some boards half soldered up) where you take a $2 USB to sd card adaptor, take off the case, solder the board to a custom made board and then add a 4PDT toggle switch to switch the SD card between the propeller and as a PC drive.

    It doesn't matter what language we are talking, GCC, large xbasic, Catalina, sooner or later we are going to have to find some solution to downloading megabyte sized files in a reasonable time.

    Another possibility is to talk USB directly. Can the propeller be setup as a USB slave? Could you send a file at max prop speeds (12 megabits???) and store it into external ram (Shift-F10?) or to SD card (Shift-F11). A supersized prop for big programs?
  • RossHRossH Posts: 5,512
    edited 2011-11-06 20:13
    David Betz wrote: »
    The code is on Google Code in the "propgcc" project under the "loader" directory. But, it might be easier if I just collect the information I need from you about your executable file format and add it myself. I'm afraid that the code may not be that easy to navigate. :-(

    Now what was it I said earlier about "reading between the lines"?

    However, you have now successfully made your point about propgcc having a faster downloader than Catalina. Not to mention propgcc using -D for defining command line symbols etc etc.

    I'll have a look at your loader code when I get time. Now can we please all agree to move on to more substantive issues?

    Ross.
  • TorTor Posts: 2,010
    edited 2011-11-06 23:43
    FWIW, I remember a huge discussion about NULL during the early years of Linux development. What I remember from that is that using (void *) 0 for NULL was considered too clever by half and created more problems than it solved. The value 0 is defined to be acceptable as valid for (all) pointers, and unless that changed with C99 it's still the case. I just checked AIX 6.1, Tru64 5.1, Solaris 10 and IRIX 6.30 and they all #define NULL as just 0.

    -Tor
  • RossHRossH Posts: 5,512
    edited 2011-11-07 00:47
    Tor wrote: »
    FWIW, I remember a huge discussion about NULL during the early years of Linux development. What I remember from that is that using (void *) 0 for NULL was considered too clever by half and created more problems than it solved. The value 0 is defined to be acceptable as valid for (all) pointers, and unless that changed with C99 it's still the case. I just checked AIX 6.1, Tru64 5.1, Solaris 10 and IRIX 6.30 and they all #define NULL as just 0.

    -Tor

    Hi Tor.

    Which is "better" is entirely a matter of personal preference. The ANSI C standard specifically allows both 0 and (void *)0. Actually, the situation is even worse - the standard does not actually mandate any specific value for NULL - it just has a bunch of rules about what a constant value of zero actually means in a pointer context (which is not the same thing at all). Other values than zero can satisfy these rules quite well - and other values have indeed been used in various compilers. See question 5.17 in the FAQ on the subject I posted earlier.

    It is quite reasonable to argue that people are "used to" the definition of NULL being zero, since it is usually true on most modern compilers (including both GCC and Catalina). But the actual rules around NULL are just a complication of C that many people simply do not understand.

    Ross.
  • David BetzDavid Betz Posts: 14,516
    edited 2011-11-07 02:58
    RossH wrote: »
    Hi Tor.

    Which is "better" is entirely a matter of personal preference. The ANSI C standard specifically allows both 0 and (void *)0. Actually, the situation is even worse - the standard does not actually mandate any specific value for NULL - it just has a bunch of rules about what a constant value of zero actually means in a pointer context (which is not the same thing at all). Other values than zero can satisfy these rules quite well - and other values have indeed been used in various compilers. See question 5.17 in the FAQ on the subject I posted earlier.

    It is quite reasonable to argue that people are "used to" the definition of NULL being zero, since it is usually true on most modern compilers (including both GCC and Catalina). But the actual rules around NULL are just a complication of C that many people simply do not understand.

    Ross.
    I don't understand why you spend so much time justifying your choice of (void *)0 as the value of NULL. It may be that it is allowed by the standard but it certainly doesn't seem to be the more common definition and since 0 is also allowed by the standard why not use the value that will cause the least trouble for people who are familiar with other compilers?
Sign In or Register to comment.