Interesting. The smiley face is in that command line.
Yes, something is definitely wrong with lcc. That output is too scrambled for me to descipher. Can you also add 2> lcc.out to the lcc command and then attach the file lcc.out? I.e.
That is not where Catalina is installed and there is no such directory on my machine. Is that the problem? Do I need to put Catalina in "C:\Program Files\Catalina"?
Yes well worth having catalina in the c:\Program Files\Catalina directory. There may be some sub folders that are referenced (certainly in the IDE I have written, it assumes this directory).
I also found typing the command line a bit tedious, so I wrote an IDE to do it for me!
That is not where Catalina is installed and there is no such directory on my machine. Is that the problem? Do I need to put Catalina in "C:\Program Files\Catalina"?
If you have Catalina installed elsewhere, you need to set the LCCDIR environment variable.
For example:
set LCCDIR=D:\Catalina
However, there is also another problem - lcc is not terminating its output with CRLF, just with LF - this would appear to indicate you are using a version of LCC that has been compiled under a Unix (or Cygwin) type environment. Is that possible? Can you please do a search on your entire hard drive for ALL versions of lcc.exe that you have installed?
Yes well worth having catalina in the c:\Program Files\Catalina directory. There may be some sub folders that are referenced (certainly in the IDE I have written, it assumes this directory).
I also found typing the command line a bit tedious, so I wrote an IDE to do it for me!
I'll give up my command line compiler when you take it from my cold dead hands!
No, I only have a single copy of lcc.exe. Can you point me to a known working release of Catalina 2.9 and I'll download again and reinstall to see if that fixes my problem.
I'll give up my command line compiler when you take it from my cold dead hands!
Te he.
Actually on a serious note, the command line program is great. What it means is that others can use the code in different ways. I actually build the command line up using text strings based on check boxes and the like.
When I get home I'll get the code that does the compilation. There are also those 'set' commands and the 'path' commands and they were added based on some discussions we had a few months ago. Rather than do them once, then forget what those commands all were years later when one ports it over to a new computer, I simply add them at the beginning of the code as a batch file.
I even copy a file from one catalina subdirectory to another subdirectory every compilation, but that is a XMM related file so not important here.
I'll post that batch file here later this evening when I get home.
No, I only have a single copy of lcc.exe. Can you point me to a known working release of Catalina 2.9 and I'll download again and reinstall to see if that fixes my problem.
I just checked the zip file I used to install Catalina C and it's dated 2011-01-22 which is the same date as the version on sourceforge. Could this all be because the LCCDIR environment variable isn't set?
Okay, I'm replying to my own message now but it seems that defining LCCDIR fixes this problem. Probably the need to set LCCDIR was mentioned in the documentation and I just missed it. I'm now running into some other problem that is probably a difference between GCC and LCC but at least I'm past the LCC problem and my Cygwin makefile now works correctly.
Okay, I'm replying to my own message now but it seems that defining LCCDIR fixes this problem. Probably the need to set LCCDIR was mentioned in the documentation and I just missed it. I'm now running into some other problem that is probably a difference between GCC and LCC but at least I'm past the LCC problem and my Cygwin makefile now works correctly.
Thanks,
David
Good!
The funny behaviour must be because the directory doesn't exist at all (which it always does on my machines, even though I often run Catalina from elswehere). I'll get LCC to print a better error message in the next version. The need to set LCCDIR is fairly prominent in the "Getting Started with Catalina" guide (page 4) but not so prominent in the "Catalina Reference Manual" (page 15 & 16). I'll also fix that in the next release.
Okay, I think I was bitten by this the last time I tried to use Catalina. I guess this is a GCC feature I'm using but I was wondering if it would be possible to support this in Catalina. The following structure definition generates an error because of the unnamed union. Any chance that unnamed unions will be supported in a future release?
struct Block {
BlockType type;
union {
struct {
int nxt;
int end;
} IfBlock;
struct {
int end;
} ElseBlock;
struct {
int nxt;
int end;
} ForBlock;
struct {
int nxt;
int end;
} DoBlock;
};
};
Unlikely - I believe the C standard is pretty explicit on this. I think this is a gcc-specific extension which probably came about accidentally when they added C++ (which does allow such things).
Okay, I'll get rid of them. I didn't realize they weren't in ANSI C when I started using them. They compile under both GCC and Microsoft Visual C++. I have to admit that I like being able to avoid having the extra level of structure reference.
struct Block {
BlockType type;
union {
struct {
int nxt;
int end;
} IfBlock;
struct {
int end;
} ElseBlock;
struct {
int nxt;
int end;
} ForBlock;
struct {
int nxt;
int end;
} DoBlock;
};
} foo;
foo.DoBlock
looks better to me than
struct Block {
BlockType type;
union {
struct {
int nxt;
int end;
} IfBlock;
struct {
int end;
} ElseBlock;
struct {
int nxt;
int end;
} ForBlock;
struct {
int nxt;
int end;
} DoBlock;
} u;
} foo;
foo.u.DoBlock
Yes, I agree it's nice - C++ got rid of a lot of the "historical baggage" that still exists in C. I may look at it one day - but at the moment I have too much other stuff on my plate to begin adding non-ANSI extensions to LCC. If it was a C99 feature I'd probably be more amenable - but it isn't.
That turned out to be the only real GCC vs. LCC problem. I have compiled xbasic and it generated an xbasic.binary file that is about 520k bytes. I guess that means it will fit in the 1mb flash on the C3! I owe you double the cost of a copy of Catalina C. Please send me a bill.
That turned out to be the only real GCC vs. LCC problem. I have compiled xbasic and it generated an xbasic.binary file that is about 520k bytes. I guess that means it will fit in the 1mb flash on the C3! I owe you double the cost of a copy of Catalina C. Please send me a bill.
Hi David,
Great! But don't you also have a DRACBLADE? If you compile using the XMM SMALL option (-x2) the resulting file should be able to be executed on that platform - also, you might use the Catalina Optimizer - that should shave off quite a few kb.
The result might not be able to handle very large basic programs, but it should run ok.
Catalina C seems very picky about pointer assignments. In particular, it doesn't like NULL being assigned to any pointer that isn't declared as a void*. I think NULL is supposed to be valid for any pointer isn't it? Why does Catalina C complain about these assignments?
I'm mainly using XMM on a dracblade. It is fast, it means you don't have to worry about running out of memory, and you can code C or Basic or even a combination of the two within the same program. I need to check out xbasic. For me, BCX basic is working well as it translates to C code that is about the same number of lines. From a very practical perspective, a 100k program is quicker to download than a 500k one.
There is still very much a place though for LMM and other smaller models, mainly for debugging functions.
Things like pointer assignments are likely to be C89 vs other variants eg C99, C++. Can you post some code?
I'm mainly using XMM on a dracblade. It is fast, it means you don't have to worry about running out of memory, and you can code C or Basic or even a combination of the two within the same program. I need to check out xbasic. For me, BCX basic is working well as it translates to C code that is about the same number of lines. From a very practical perspective, a 100k program is quicker to download than a 500k one.
I think we will eventually find that BCX is good at producing fast compiled basic code, whereas David's xbasic is an interpreter. Is that correct David?
My examples were pointers to functions. Maybe they have different rules.
I get a warning to the effect that the conversion from a 'pointer to void' to a function pointer is compiler dependent. Is that what you mean?
Well, in fact it is - in C there is no requirement that a function pointer even be the same length as a data pointer, so pointer conversion between the two is "iffy" on platforms that have different code and data address spaces - or rather it is for every pointer except the NULL pointer (which always has the value zero). I agree lcc should not issue a warning if the value of the pointer is in fact NULL.
The syntax for pointers to functions is a bit obscure - but here is one that generates the warning:
#include <stdlib.h>
typedef int (* func_ptr) (int b);
void main () {
func_ptr a;
a = NULL; // <--- this is a valid assignment, but it produces a warning
a = 0; // <--- this is also a valid assignment, and produces no warning
}
EDIT: Just noticed that lcc is inconsistent in its treatment of 0 and (void *)0 - both are valid null pointer constants - but one generates the warning and one doesn't. A minor issue - I'll fix it when I get time.
Comments
Interesting. The smiley face is in that command line.
Yes, something is definitely wrong with lcc. That output is too scrambled for me to descipher. Can you also add 2> lcc.out to the lcc command and then attach the file lcc.out? I.e.
Ross.
That is not where Catalina is installed and there is no such directory on my machine. Is that the problem? Do I need to put Catalina in "C:\Program Files\Catalina"?
I also found typing the command line a bit tedious, so I wrote an IDE to do it for me!
If you have Catalina installed elsewhere, you need to set the LCCDIR environment variable.
For example:
However, there is also another problem - lcc is not terminating its output with CRLF, just with LF - this would appear to indicate you are using a version of LCC that has been compiled under a Unix (or Cygwin) type environment. Is that possible? Can you please do a search on your entire hard drive for ALL versions of lcc.exe that you have installed?
Ross.
I'll give up my command line compiler when you take it from my cold dead hands!
Thanks,
David
Te he.
Actually on a serious note, the command line program is great. What it means is that others can use the code in different ways. I actually build the command line up using text strings based on check boxes and the like.
When I get home I'll get the code that does the compilation. There are also those 'set' commands and the 'path' commands and they were added based on some discussions we had a few months ago. Rather than do them once, then forget what those commands all were years later when one ports it over to a new computer, I simply add them at the beginning of the code as a batch file.
I even copy a file from one catalina subdirectory to another subdirectory every compilation, but that is a XMM related file so not important here.
I'll post that batch file here later this evening when I get home.
Hi David,
Get it from the sourceforge site - http://sourceforge.net/projects/catalina-c/files/releases/2.9/Catalina_2.9_Win32.zip/download
Thanks,
David
Good!
The funny behaviour must be because the directory doesn't exist at all (which it always does on my machines, even though I often run Catalina from elswehere). I'll get LCC to print a better error message in the next version. The need to set LCCDIR is fairly prominent in the "Getting Started with Catalina" guide (page 4) but not so prominent in the "Catalina Reference Manual" (page 15 & 16). I'll also fix that in the next release.
Ross.
struct Block { BlockType type; union { struct { int nxt; int end; } IfBlock; struct { int end; } ElseBlock; struct { int nxt; int end; } ForBlock; struct { int nxt; int end; } DoBlock; }; };Unlikely - I believe the C standard is pretty explicit on this. I think this is a gcc-specific extension which probably came about accidentally when they added C++ (which does allow such things).
Ross.
struct Block { BlockType type; union { struct { int nxt; int end; } IfBlock; struct { int end; } ElseBlock; struct { int nxt; int end; } ForBlock; struct { int nxt; int end; } DoBlock; }; } foo; foo.DoBlocklooks better to me than
struct Block { BlockType type; union { struct { int nxt; int end; } IfBlock; struct { int end; } ElseBlock; struct { int nxt; int end; } ForBlock; struct { int nxt; int end; } DoBlock; } u; } foo; foo.u.DoBlockYes, I agree it's nice - C++ got rid of a lot of the "historical baggage" that still exists in C. I may look at it one day - but at the moment I have too much other stuff on my plate to begin adding non-ANSI extensions to LCC. If it was a C99 feature I'd probably be more amenable - but it isn't.
Ross.
Thanks Ross!
Hi David,
Great! But don't you also have a DRACBLADE? If you compile using the XMM SMALL option (-x2) the resulting file should be able to be executed on that platform - also, you might use the Catalina Optimizer - that should shave off quite a few kb.
The result might not be able to handle very large basic programs, but it should run ok.
Ross.
P.S. The bill is in the post!
There is still very much a place though for LMM and other smaller models, mainly for debugging functions.
Things like pointer assignments are likely to be C89 vs other variants eg C99, C++. Can you post some code?
Correct. Can you post some code? It may depend on your definition of NULL.
The example I just compiled which gets its definition from stdlib.h as (void *)0 works for me:
#include <stdlib.h> void main () { char *a; a = NULL; }I think we will eventually find that BCX is good at producing fast compiled basic code, whereas David's xbasic is an interpreter. Is that correct David?
Ross.
I get a warning to the effect that the conversion from a 'pointer to void' to a function pointer is compiler dependent. Is that what you mean?
Well, in fact it is - in C there is no requirement that a function pointer even be the same length as a data pointer, so pointer conversion between the two is "iffy" on platforms that have different code and data address spaces - or rather it is for every pointer except the NULL pointer (which always has the value zero). I agree lcc should not issue a warning if the value of the pointer is in fact NULL.
Ross.
Can you post the code that produces the error?
Hi Dr_A,
The syntax for pointers to functions is a bit obscure - but here is one that generates the warning:
#include <stdlib.h> typedef int (* func_ptr) (int b); void main () { func_ptr a; a = NULL; // <--- this is a valid assignment, but it produces a warning a = 0; // <--- this is also a valid assignment, and produces no warning }EDIT: Just noticed that lcc is inconsistent in its treatment of 0 and (void *)0 - both are valid null pointer constants - but one generates the warning and one doesn't. A minor issue - I'll fix it when I get time.Sorry I took so long to reply. I was in the Propeller Meetup.