If I compile the following code with the 3/06/12 update the word variables get converted to longs.
'Chip settings
#chip 18F27J13, 8
#config OSC = INTOSC, WDTEN = OFF, ADCSEL = BIT12
'dim ADresult as word alias ADRESH, ADRESL
dim resistor, ref10k, ref100k, ref1M as word
dim thermistor, testResistance as long
do
loop
This is a section of the assembly file with all the word variables taking up 4 locations.
The problem goes away if you dimension all the long variables on individual lines or dim the words after the longs. Aliased word variables are also affected - they don't get an alias in the assembly file and an error is generated if its assigned to another variable.
Can someone else confirm this behaviour?
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's definitely a bug! I've uploaded a slightly changed update.zip that should fix it.
The problem occured when reading the Dim command. When there are multiple variables on a line, GCBASIC splits up the list at the commas, stores each name in an array, and then adds them individually. The only problem is it wasn't clearing the list properly, so each Dim command was adding not only the variables from that command, but the variables from any lines before it.
Alias variables won't be listed in the assembly file unless they are accessed somewhere in the code. If you add something to the program that uses the alias, the aliases should appear in the assembly. (This is something I'll probably add for normal variables in the future. For aliases it's pretty pointless, but for other variables it's a way to save RAM in the event of a variable being declared but not used.)
There is one more difficult problem though, and that is the chip data file for the 18F27j13. It seems to be missing the information on what config words are present on the chip. I haven't quite got time now, but I'll try to fix those up some time in the next few days. Until then you'll need to either set the configuration manually with the programmer or look for a similar PIC and copy over the relevant section of the chip data. Sorry about that!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I compile the following code with the 3/06/12 update the word variables get converted to longs.
This is a section of the assembly file with all the word variables taking up 4 locations.
The problem goes away if you dimension all the long variables on individual lines or dim the words after the longs. Aliased word variables are also affected - they don't get an alias in the assembly file and an error is generated if its assigned to another variable.
Can someone else confirm this behaviour?
Frank
That's definitely a bug! I've uploaded a slightly changed update.zip that should fix it.
The problem occured when reading the Dim command. When there are multiple variables on a line, GCBASIC splits up the list at the commas, stores each name in an array, and then adds them individually. The only problem is it wasn't clearing the list properly, so each Dim command was adding not only the variables from that command, but the variables from any lines before it.
Alias variables won't be listed in the assembly file unless they are accessed somewhere in the code. If you add something to the program that uses the alias, the aliases should appear in the assembly. (This is something I'll probably add for normal variables in the future. For aliases it's pretty pointless, but for other variables it's a way to save RAM in the event of a variable being declared but not used.)
There is one more difficult problem though, and that is the chip data file for the 18F27j13. It seems to be missing the information on what config words are present on the chip. I haven't quite got time now, but I'll try to fix those up some time in the next few days. Until then you'll need to either set the configuration manually with the programmer or look for a similar PIC and copy over the relevant section of the chip data. Sorry about that!
Thanks Hugh. That was a mighty quick fix.
I'd cobbled together a config section for the 18F27J13 but then forgot about it not being a good choice for the code example.