GCBASIC / Discussion / Compiler Problems: Developer Help Needed

Anobium - 2024-01-11

I am looking for a developer to help improve the performance of the compiler.

The project goal is to change the behaviour of the compiler in the way the preprocessor operates. Currently, the compiler searches through all the source files to find specific strings. Those command strings include anything that starts with a '#' and these searches happen on every line for every command.

The project will tokenise these command strings by extending the data model. Then, the searches will use the tokens rather than string searches.

The background to this ? Last month I introduced a new command. The new command had a huge impact on the performance of the compiler, the compiler was taking greater than 34s rather than normal sub 10s. This huge time increase led me to think that coukld the compiler be faster if tokenisation could be implemented ?

This is a standalone project and this project must meet the project goals, shown below, to have these changes merged into the Master baseline code.

Success will be a faster compiler.

All the tools and source code required is installed with every GCSTUDIO installation.

Are you able and willing to help ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-01-30

Is this file that takes 34s available for testing? The worst file I have takes less than 3s to make the asm (I'm assuming that compiling to asm is really the only part to focus on).

Is this to make changes to gcbasic.exe itself, or to the gawk stuff (preprocessor as you stated above)?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2024-01-30
  
  Great questions.
  
  We do not use the AWK preprocessor when using GCCODE as the IDE. So, these timing are all related to the compilation process.
  
  The 34s was when I made a smaller change to the compiler. I spotted the time increase before I published.
  
  The compiler takes about 3s to preprocessor using the current method. It this 3s that should be a lot faster.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-01-30

I remember seeing it somewhere, but I can't find now when I want it. What version of freebasic are you using to compile and link gcbasic for 64 bit? I want to put some timetags on the stuff it prints out when running.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2024-01-30

Sure.

All the FreeBASIC software is installed in your GCSTUDIO installation. Have a look at the folder structure for the installation folder.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-01-31

As you literally said in the first post. Duh.

I used:
H:\GCstudio\FBASIC\x64\fbc -exx -arch 586 "gcbasic.bas"
and got the error:
Executable not found: "H:\GCstudio\FBASIC\x64\bin\win32\as.exe"
Haven't found where it's getting that string with win32 instead of win64

When I did 32 bit:
H:\GCstudio\FBASIC\x86\fbc -exx -arch 586 "gcbasic.bas"
It ran perfectly.

Guess I'll just use 32bit for now.

Thanks for your patience.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Angel Mier - 2024-01-31

This is a video of how you and any one interested can easily do changes in the code of the compiler, test and go back to normal (Excuse my bad English accent/pronunciation)

https://www.youtube.com/watch?v=KumsXvloBmk

Dev Environment is on the Settings Panel as can be seen on the video

Notes:

The source code is always up to date to the current version via the auto update

Keep a backup of your changes because if an update is available it will update the source code, or see the other option in the video (disable updates temporarily)

the default command to build is:
"${env:GCBASIC_INSTALL_PATH}\FBASIC\x86\fbc.exe gcbasic.bas -arch 586 -exx -x gcbasic.exe"

And you can change it if you wish on: "gcbasic\.vscode\task.json" or clicking on the settings button on the build task.
Current version of fbasic on GCstudio is: 1.07.1

Hope it helps

👍
1

Last edit: Angel Mier 2024-02-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-01-31

Thank Angel, very well done. You've put a great deal of work in this and it is appreciated.
Until I can get into all that, I'm just doing simple quickies using fbedit which I'm much more comfortable with.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Angel Mier - 2024-01-31

Just for Thoughts or Brainstorming:

If the preprocessor should access all source/library files; may be, if it append them and search on them on multiple threads (one thread per sorce/lib file) , and wait for all threads to finish, then go to the next section of the code, it should be much faster and use hardware (PC) resources better.

In example, if the preprocessor must search on 12 sources:

On a single thread the compiler will go one source at a time until it finished the 12 files, and take more time no mater what system or good hardware you have (a lot of cpu performance is unused)

On multi thread it will append all files and that process should take only the time it takes to process the biggest file of the bunch (but only 1) as the others will finish early, here the performance will scale as the more files the project have and the more powerful the hardware is, (and even on one core cpu's the performance should still be better because of the better handling of resources)

Some info on fbasic multitasking:
https://www.freebasic.net/wiki/ProPgMultiThreading
https://www.freebasic.net/wiki/ProPgMtThreads

Thank you Jim for jumping in, I hope more people want to join also.

Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2024-01-31
  
  This is interesting because the sequential loading of all the source and includes could be the costly delay. The threads could load the files into separate lists and then the main thread load each thread list into the master list. Could be the saving of a few seconds.
  
  Could work to improve performance.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-01

So I ran some tests using the worst file I could find in the demos with the internal comment of
"this program is a simple GLCD demonstration of the ILI9341 GLCD capabilities".
I just added some code to keep track of how long each section ran and some prints, no other changes.

This is the results:

K:\gcbasic-code-r1580-GCBASIC-trunk>GCBASIC.EXE zzztest.gcb /R:text /NP /H:N /P:
GCBASIC (1.01.00 2024-01-08 (Windows 32 bit) : Build 1324)

Compiling zzztest.gcb
loading 54 source files
Program compiled successfully (Compile time: 4.734 seconds)

Summary:
Compiled:
Program lines: 32749
Subroutines: User: 3 ; System: 42 of 1025 ; Total: 45
Chip resource usage:
Program Memory: 7861/16384 words (47.98%)
RAM: 334/2048 bytes (16.31%)
OSC: HFINTOSC_1MHZ, 64Mhz (Internal oscillator)
Done

0.0820 et everything up to doing source files
2.0820 et everything within loading source files
0.6562 et everything between loading source files and compiling
1.4101 et everything within compile
0.5078 et everything after compile
Total 4.7381

I think it is your intention to focus on the part that loads source files, correct?

These times don't look terrible to me. Do you have a better test file to use? Or what would be the criteria to create a test file that demonstrates the problem?

I haven't isolated the part that reads the same file over and over as I think you were implying in the first post.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2024-02-02

Good insights.

I am right that is took 2 seconds to load the source files? That is huge in the overall end to end process.

I should clarify. The re-reading of the source files is within the PREPROCESSOR method. There is an IF statement that checks for a "#", then, examines many time for the all the # statements.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-02

Yes, it takes about 44% of the time to read through the source files in that portion of the preprocessor. Here is a recent result of running-

..........................................................
K:\gcbasic-code-r1580-GCBASIC-trunk>GCBASIC.EXE zzztest.gcb /R:text /NP /H:N /P:
GCBASIC (1.01.00 2024-01-08 (Windows 32 bit) : Build 1324)

Compiling zzztest.gcb
loading 54 source files
0.0386 average processing time per file
Program compiled successfully (Compile time: 4.736 seconds)

Summary:
Compiled:
Program lines: 32749
Subroutines: User: 3 ; System: 42 of 1025 ; Total: 45
Chip resource usage:
Program Memory: 7861/16384 words (47.98%)
RAM: 334/2048 bytes (16.31%)
OSC: HFINTOSC_1MHZ, 64Mhz (Internal oscillator)
Done

1.72% 0.0820 et everything up to doing source files
44.0% 2.0878 et everything within loading source files
13.9% 0.6601 et everything between loading source files and compiling
29.5% 1.4023 et everything within compile
10.7% 0.5097 et everything after compile
Total 4.742188
...........................................................................

Reading the 54 source files in the preprocessor took 44% of the time, but each file only took on average .0386 seconds.

I'm looking into that section now.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-03

I printed out a log file the name of each file as it was opened. It turns out that 30 of the files were read twice. Only twice. So it processed 54+30=84 files in 2.0878 seconds or 0.025 seconds per file. I could not find any instance of it moving the file pointer using seek, so it wasn't reading files multiple times that way.

Unless you have a special case file you want handled, I don't see any advantage to tokenizing the files for only two uses of some files.

I'm not saying that there aren't some other places that could be optimized, but the gain probably wouldn't be that great.

I'm going to single step through a pass to see if there is something I'm missing.

Last edit: Jim giordano 2024-02-10

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2024-02-03
  
  A good analysis.
  
  What files are read twice? and, why?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-03

The following were read twice
...\include\epd_epd2in13d.h
...\include\epd_epd7in5.h
...\include\glcd.h
...\include\glcd_hx8347.h
...\include\glcd_ili9326.h
...\include\glcd_ili9340.h
...\include\glcd_ili9341.h
...\include\glcd_ili9481.h
...\include\glcd_ili9486l.h
...\include\glcd_ili9488.h
...\include\glcd_ks0108.h
...\include\glcd_lt7686.h
...\include\glcd_nextion.h
...\include\glcd_nt7108c.h
...\include\glcd_pcd8544.h
...\include\glcd_sh1106.h
...\include\glcd_ssd1289.h
...\include\glcd_ssd1306.h
...\include\glcd_ssd1306_twin.h
...\include\glcd_ssd1331.h
...\include\glcd_ssd1351.h
...\include\glcd_st7567.h
...\include\glcd_st7735.h
...\include\glcd_st7735r.h
...\include\glcd_st7789.h
...\include\glcd_st7920.h
...\include\glcd_t6963.h
...\include\glcd_uc1601.h
...\include\glcd_uc8230.h
...\include\levetop1024x600.h
...\include\levetop800x480.h
...
zzztest.gcb
zzztest.gcb

The following were read only once
...\include\lowlevel.dat
...\INCLUDE\LOWLEVEL\7segment.h
...\INCLUDE\LOWLEVEL\a-d.h
...\INCLUDE\LOWLEVEL\eeprom.h
...\INCLUDE\LOWLEVEL\hef.h
...\INCLUDE\LOWLEVEL\hwi2c.h
...\INCLUDE\LOWLEVEL\hwi2c2.h
...\INCLUDE\LOWLEVEL\hwspi.h
...\INCLUDE\LOWLEVEL\i2c.h
...\INCLUDE\LOWLEVEL\keypad.h
...\INCLUDE\LOWLEVEL\lcd.h
...\INCLUDE\LOWLEVEL\picas.h
...\INCLUDE\LOWLEVEL\ps2.h
...\INCLUDE\LOWLEVEL\pwm.h
...\INCLUDE\LOWLEVEL\pwm16.h
...\INCLUDE\LOWLEVEL\random.h
...\INCLUDE\LOWLEVEL\rs232.h
...\INCLUDE\LOWLEVEL\saf.h
...\INCLUDE\LOWLEVEL\sound.h
...\INCLUDE\LOWLEVEL\spisram.h
...\INCLUDE\LOWLEVEL\stdbasic.h
...\INCLUDE\LOWLEVEL\string.h
...\INCLUDE\LOWLEVEL\system.h
...\INCLUDE\LOWLEVEL\timer.h
...\INCLUDE\LOWLEVEL\usart.h

don't know just why yet.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2024-02-03
  
  They are listed in glcd.h
  
  I thought... these would be loaded once. But, I have no idea why they are loaded twice.
  
  Try to figure out why they are loaded. This would save some time when loaded only once.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-03

perhaps seeing every file opened and read in order might help-

Open1, input as #1 zzztest.gcb
Open1, input as #1 ...\include\glcd.h
Open1, input as #1 ...\include\glcd_st7789.h
Open1, input as #1 ...\include\glcd_ks0108.h
Open1, input as #1 ...\include\glcd_nt7108c.h
Open1, input as #1 ...\include\glcd_ssd1306.h
Open1, input as #1 ...\include\glcd_uc1601.h
Open1, input as #1 ...\include\glcd_ssd1306_twin.h
Open1, input as #1 ...\include\glcd_ili9341.h
Open1, input as #1 ...\include\glcd_ili9340.h
Open1, input as #1 ...\include\glcd_ssd1289.h
Open1, input as #1 ...\include\glcd_st7735.h
Open1, input as #1 ...\include\glcd_st7735r.h
Open1, input as #1 ...\include\glcd_st7920.h
Open1, input as #1 ...\include\glcd_pcd8544.h
Open1, input as #1 ...\include\glcd_sh1106.h
Open1, input as #1 ...\include\glcd_ili9326.h
Open1, input as #1 ...\include\glcd_ssd1351.h
Open1, input as #1 ...\include\glcd_ili9486l.h
Open1, input as #1 ...\include\glcd_ili9488.h
Open1, input as #1 ...\include\glcd_ili9481.h
Open1, input as #1 ...\include\glcd_hx8347.h
Open1, input as #1 ...\include\glcd_ssd1331.h
Open1, input as #1 ...\include\glcd_nextion.h
Open1, input as #1 ...\include\glcd_t6963.h
Open1, input as #1 ...\include\glcd_uc8230.h
Open1, input as #1 ...\include\epd_epd2in13d.h
Open1, input as #1 ...\include\epd_epd7in5.h
Open1, input as #1 ...\include\glcd_st7567.h
Open1, input as #1 ...\include\glcd_lt7686.h
lowlevel, input as #1 ...\include\lowlevel.dat
Open2, input as #1 zzztest.gcb
Open2, input as #1 ...\include\glcd.h
Open2, input as #1 ...\include\glcd_st7789.h
Open2, input as #1 ...\include\glcd_ks0108.h
Open2, input as #1 ...\include\glcd_nt7108c.h
Open2, input as #1 ...\include\glcd_ssd1306.h
Open2, input as #1 ...\include\glcd_uc1601.h
Open2, input as #1 ...\include\glcd_ssd1306_twin.h
Open2, input as #1 ...\include\glcd_ili9341.h
Open2, input as #1 ...\include\glcd_ili9340.h
Open2, input as #1 ...\include\glcd_ssd1289.h
Open2, input as #1 ...\include\glcd_st7735.h
Open2, input as #1 ...\include\glcd_st7735r.h
Open2, input as #1 ...\include\glcd_st7920.h
Open2, input as #1 ...\include\glcd_pcd8544.h
Open2, input as #1 ...\include\glcd_sh1106.h
Open2, input as #1 ...\include\glcd_ili9326.h
Open2, input as #1 ...\include\glcd_ssd1351.h
Open2, input as #1 ...\include\glcd_ili9486l.h
Open2, input as #1 ...\include\glcd_ili9488.h
Open2, input as #1 ...\include\glcd_ili9481.h
Open2, input as #1 ...\include\glcd_hx8347.h
Open2, input as #1 ...\include\glcd_ssd1331.h
Open2, input as #1 ...\include\glcd_nextion.h
Open2, input as #1 ...\include\glcd_t6963.h
Open2, input as #1 ...\include\glcd_uc8230.h
Open2, input as #1 ...\include\epd_epd2in13d.h
Open2, input as #1 ...\include\epd_epd7in5.h
Open2, input as #1 ...\include\glcd_st7567.h
Open2, input as #1 ...\include\glcd_lt7686.h
temp, input as # 2 ...\include\levetop800x480.h
temp, input as # 2 ...\include\levetop1024x600.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\picas.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\a-d.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\pwm.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\rs232.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\eeprom.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\sound.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\stdbasic.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\7segment.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\lcd.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\ps2.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\timer.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\system.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\hwspi.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\keypad.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\random.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\string.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\usart.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\i2c.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\hwi2c.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\hwi2c2.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\pwm16.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\saf.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\hef.h
Open2, input as #1 ...\INCLUDE\LOWLEVEL\spisram.h

Open1 and Open2 are the two main open commands in the preprocessor.
Note that they are in no way nested.
cdf and lowlevel are other opens I didn't report earlier.
There is also an open for DataTable that didn't occur this run.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2024-02-03

I would need to see the source.gcb.

lowlevel.dat has no reference to glcd.h so, this is not the root cause of the second load.

I have no idea why they are loading twice.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-03

it is the demo file
\GCstudio\gcbasic\demos\Vendor_Boards\Great_Cow_Basic_Demo_Board\18F25K42_ChipRange_Demonstrations\340_SPI_GLCD_with_Touch_using_ili9341.gcb

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2024-02-03
  
  Nothing obvious in the source file. Back to you. :-)
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-03

Also, I have no problem with it reading the files twice. It's a two pass compiler, quite normal. Read the files to figure out what you need, get the stuff, read again to apply the stuff. These files are so small that I'm sure windows keeps a copy in memory after the first read for immediate use again without physical disk access. And two pass compilers are nice since you don't have to put in a bunch of superfluous declares up front. I've always felt that if the compiler can read the first line of a subroutine and know immediately what it needs, it's stupid to require the coder to put that declaration redundantly up front.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2024-02-04

The number of passes by the compiler should not affect the number of times the files are loaded.

Looks to me like we need resolve the loading of the unneeded GLCDs.

Try this... replace all #include ... in glcd.h with //#include ..., then, enable the one we are using ILI9341.

I knocked off 2 secs off the compile time.

Do you see the the same result?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2024-02-04

If you get the same result, in terms of time reduction, then I think you could change the compiler behaviour.

Remove all the #include from glcd.h

Add new file glcdl.dat for these optional glcd libraries

Change the compiler to examine for #INCLUDE <glcd.h> in the user program, then look for GLCD_TYPE and load the specific GLCD library.

Users could still override by including the full specification of the library, as follows:

#INCLUDE <glcd.h> #include <glcd_ili9341.h> #INCLUDE <xpt2046.h> #DEFINE GLCD_TYPE GLCD_TYPE_ILI9341

My afterthoughts.

The compiler is getting slower to compiler as more and more syntax checking is added. It can only get slower.

The recently added GLCDs is why I noticed the overall timing was slower now. The new GLCDs use tables to stream a load of setup data to the 7inch screens. Tables are slow ( all relative of course :-) ).

So, as more GLCDs are added the slower the compiler will get. :-(

A new file called glcd.dat and this has the information to optional add the correct library.

You can then copy the code for managing and loading lowlevel.dat ( including the Linux code) and it will work. Note some of the entries in this new dat file have the same index, so, these can be ignored when loading.

I would recommend the following approach to load the correct GLCD library.

The goal is to load one GLCD library only when needed - this will speed up everything for everyone.

Change the For RF- Next loop to a Do While RF <= SourceFiles Loop Set RF = 0 before the new Do-Loop. And, increment RF each time throught the loop In the #DEFINE test, if the usersource program and the GLCD_TYPE constant exists, add the code to extract the correct GLCD library from GLCD.DAT and then add this filename to the sourcefile array, incrementing the SourceFiles variables. Now the new Do While RF <= SourceFiles Loop will open only this specfic GLCD library.

Edit, GLCD.H to remove all #includes and it will be faster!

in theory.

Last edit: Anobium 2024-02-04

glcd.dat
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jim giordano - 2024-02-04

Try this... replace all #include ... in glcd.h with //#include ..., then, enable the one we are using ILI9341.

okay, now I'm really confused.
I commented all the includes except ILI9341, as you said, and I got a bunch of errors as follows:
glcdx.h * (5132): Error: Lookup table BIGFONT32_41 not found (Library Include)
glcdx.h * (5132): Error: Syntax Error (Library Include)
glcdx.h * (5133): Error: Lookup table BIGFONT42_51 not found (Library Include)
glcdx.h * (5133): Error: Syntax Error (Library Include)
glcdx.h * (5134): Error: Lookup table BIGFONT52_61 not found (Library Include)
glcdx.h * (5134): Error: Syntax Error (Library Include)
glcdx.h * (5135): Error: Lookup table BIGFONT62_71 not found (Library Include)
glcdx.h * (5135): Error: Syntax Error (Library Include)
glcdx.h * (5136): Error: Lookup table BIGFONT72_81 not found (Library Include)
glcdx.h * (5136): Error: Syntax Error (Library Include)
glcdx.h * (5137): Error: Lookup table BIGFONT82_91 not found (Library Include)
glcdx.h * (5137): Error: Syntax Error (Library Include)
glcdx.h * (5138): Error: Lookup table BIGFONT92_101 not found (Library Include)
glcdx.h * (5138): Error: Syntax Error (Library Include)
glcdx.h * (5139): Error: Lookup table BIGFONT102_111 not found (Library Include)
glcdx.h * (5139): Error: Syntax Error (Library Include)
glcdx.h * (5140): Error: Lookup table BIGFONT112_121 not found (Library Include)
glcdx.h * (5140): Error: Syntax Error (Library Include)
glcdx.h * (5141): Error: Lookup table BIGFONT122_126 not found (Library Include)
glcdx.h * (5141): Error: Syntax Error (Library Include)
glcdx.h * (5142): Error: Lookup table BIGFONT193_202 not found (Library Include)
glcdx.h * (5142): Error: Syntax Error (Library Include)
glcdx.h * (5143): Error: Lookup table BIGFONT203_212 not found (Library Include)
glcdx.h * (5143): Error: Syntax Error (Library Include)
glcdx.h * (5144): Error: Lookup table BIGFONT213_216 not found (Library Include)
glcdx.h * (5144): Error: Syntax Error (Library Include)

But, what really confuses me it that the includes that were commented out, were in an if that was false, so it seem that the intent was that they should never have been loaded al all.
There is a
#DEFINE GLCD_TYPE GLCD_TYPE_ILI9341
in the program, so, for example, the code-

If GLCD_TYPE = GLCD_TYPE_ST7789_320_240 Then
#include <glcd_st7789.h>
InitGLCD = InitGLCD_ST7789
GLCDCLS = GLCDCLS_ST7789
GLCDDrawChar = GLCDDrawChar_ST7789
GLCDDrawString = GLCDDrawString_ST7789
FilledBox = FilledBox_ST7789
Pset = Pset_ST7789
GLCDRotate = GLCDRotate_ST7789
glcd_type_string = "ST7789"
GLCD_WIDTH = 320
GLCD_HEIGHT = 240
ST7789_GLCD_HEIGHT = GLCDDeviceHeight
ST7789_GLCD_WIDTH = GLCDDeviceWidth
End If</glcd_st7789.h>

says include GLCD_ST7789.h if GLCD_TYPE = GLCD_TYPE_ST7789_320_240, which it isn't. But the preprocessor can't evaluate the if statement at preprocessor time, so the include is processed regardless of the if. So you might as well have just put all the includes for all the glcd's up front rather than in ifs.

Should not all these ifs have been #ifs so the #includes won't load? And indeed no need to load and compile any of the code in the if.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Developer Help Needed

Forums

Help

Developer Help Needed document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

This is a video of how you and any one interested can easily do changes in the code of the compiler, test and go back to normal (Excuse my bad English accent/pronunciation)

Just for Thoughts or Brainstorming:

Developer Help Needed