With two blocks defined the first one effects the second. Remove the first and all is good:
'#define 10f
#define 16f
#ifdef 10f
#chip 10f204,1
#endif
#ifdef 16f
#chip 16F690,4
#config LP_OSC, wdt_off, mclre_off, cp_off
#endif
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, this was a bad design decision on my part that will be rather hard to fix.
GCBASIC doesn't process the preprocessor directives from top to bottom. Rather, it reads the #include directives first, and adds each found file to a list (rather than replacing the #include with the included file like a preprocessor should). The lowlevel includes are then added to the file list, and it reads the files in the order they are found in the list. Then, it reads #define, #config and #chip lines, and then processes the #ifdefs. So a directive inside an #ifdef will always get processed, even if it shouldn't.
The trouble is that changing the order of things would break the included GCBASIC libraries, and may cause problems for other peoples' code. For example, some #ifdefs would occur before the constant that controls them is defined, which would lead to code being removed that should stay in there.
Hopefully this can be fixed without causing major headaches sometime over the next few months, but until then the preprocessor will have to stay the way it is to avoid breaking existing code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With two blocks defined the first one effects the second. Remove the first and all is good:
'#define 10f
#define 16f
#ifdef 10f
#chip 10f204,1
#endif
#ifdef 16f
#chip 16F690,4
#config LP_OSC, wdt_off, mclre_off, cp_off
#endif
Found that the problem lies with #chip following the unflagged define. It is ALWAYS setting the CPU, even if its outside the Define!!!
Unfortunately, this was a bad design decision on my part that will be rather hard to fix.
GCBASIC doesn't process the preprocessor directives from top to bottom. Rather, it reads the #include directives first, and adds each found file to a list (rather than replacing the #include with the included file like a preprocessor should). The lowlevel includes are then added to the file list, and it reads the files in the order they are found in the list. Then, it reads #define, #config and #chip lines, and then processes the #ifdefs. So a directive inside an #ifdef will always get processed, even if it shouldn't.
The trouble is that changing the order of things would break the included GCBASIC libraries, and may cause problems for other peoples' code. For example, some #ifdefs would occur before the constant that controls them is defined, which would lead to code being removed that should stay in there.
Hopefully this can be fixed without causing major headaches sometime over the next few months, but until then the preprocessor will have to stay the way it is to avoid breaking existing code.