Positron libraries

[Wimax]

Hello everybody

It has sometimes happened to me that I have made changes to certain libraries after having included them in the main programme, thus affecting the original files. The changes were often triggered by the specifics of the individual MCU of the same family. Is it possible to make libraries included in a programme become local copies, integral parts of the project itself, so that by intervening on them from within the project, the originals are not modified ?

[Gamboa]

Wimax,

In each project I put a copy of the libraries and the main .BAS file in the same project folder. This way, if I need to modify anything in any library it is modified locally. I make the copy manually when starting. the project.

Regards,
Gamboa

[John Lawton]

I once struggled with this myself.

Les has explained how the compiler uses files:
https://protoncompiler.com/index.php?msg=4133

On one project, it didn't seem to be working like that so to ensure I was using the right include files I put the modified copies in the main project source folder and in the Include statements used the full file path to those files.

Alternatively change the file names before including them to ensure only those unique files are the ones being used.

[Stephen Moss]

Is it possible to make libraries included in a programme become local copies, integral parts of the project itself,

I am not quite sure what you mean by making it an integral part of the project but as I see it you have 3 options...

• Copy the library file code into your main program file as a subroutine or procedure, thereby fully integrating it into your code file
• Make the changes then Save As, to save the modified version in the same folder as the other library items but with a different name indicating it is an altered version
• When I start a new project I always create a separate folder for it, if you do that you could place a copy of the relevant Library file in there and use that one, thereby leaving the original unaltered

I never modify an original file is case I mess it up so it does not work at all, but mostly because there is always the possibility that the original author updates it and whatever changes I have made will be lost during a subsequent update as the file is then overwritten.
Which of the options above works best for you will depend on how you are modifying the file, if you are using the $If, $ElseIf and $EndIf directives to execute slightly different line, i.e....

Code Select Expand

$if _device = _18F452 then
TCON1 = x    'Equivalent Register Name for 18F452
$elseif
TCON = x     'Standard Register name
$endif

(I think that is how it works as I have never done it myself) the option 2 above may be the better method, otherwise options 1 or 3 may be better.

[top204]

If a ".inc" file is placed in the folder where the ".bas" file is, the ".bas" program listing will use that file when the Include directive is used. However, if the ".inc" file is within the compilers "Includes" folder, and not in the ".bas" file, it will use that, because all the ".inc" files in the "Includes" folder are visible to all code listings.

The Includes folder is located at: "C:\Users\User Name\PDS\Includes\".

However, any changes to an existing file in the "Includes" folder will be removed when the compiler is updated, because they will be replaced with the original files in the installer, because they are the library files for the compiler and not user library files.

So it is better to either place the ".inc" file in the ".bas" file's folder if changes are made to it, or change the name of the ".inc" file in the "Includes" folder, so it will not be overwritten by an update or upgrade, and other program listing can also see it and use it.

[Frizie]

I think I'll get some comments on this, but I haven't used include files for years anymore.
Besides the advantages, there are also disadvantages.

After opening an 8-year-old program, it turned out that include files were missing 
Where they are? No idea.

I now always copy the code that would normally be placed in an include file directly into the main program, so I know for sure that it is always there.
With using procedures this is very easy 

[joesaliba]

I always include a file where the main.bas file is.

However, I noticed that when I have a lot of DIM in various include files, these are not always work as expected in the main program. Could not track down why.

[John Lawton]

Les will correct me but I believe the compiler reads all the source code files and creates just one file containing all the source code and then processes that. So you <should> get the same result as if you put all your code in one file.

But perhaps your Include files weren't all loaded at the same time or in the same sequence as when you moved some DIM statements into the main .bas file so the variables ended up in different parts of memory which can change the end result in subtle ways?

[JonW]

I always use include files now, mainly to simplify the main code listing and help to reuse libraries I have built.  I keep any .inc files local and keep every new listing in its own folder with includes, etc. An MYLIB folder has copies of every .inc file, with detailed information on the use and the proc calls; variables used and an example .bas.   I then have a BAK and Archive folder within the main project folder.  I then set milestones in the coding process and back up on a milestone, plus per day.  Archived files are major revisions from a release and are .bas or .inc files.  Once built and released, I also add a Current Release file with everything in it plus the .hex, all date-coded and zipped up.   I then shadow the full folders to Git and a remote server.

[top204]

John is correct. Include files are merged with the main ".bas" file at the location of the Include directive by the "Loader.exe" file, then preprocessed. So the compiler sees a larger file to compile, and the "Loader.exe" files names it with an extension of ".bin" before it is passed to the actual compiler file: "Pos8.exe" or "Pos16.exe", so it is the equivalent of adding the code to the ".bas" file, but makes it smaller and easier to read.

In the Positron8 compiler, a variable used in a program before its Dim creates it will not always be correctly identified as the correct type, so "always" add Include directives at the beginning of a ".bas" code listing, and before any actual compiling must take place, which is a bit like C compilers, that also 'sometimes' suffer from this type of thing.

This is a throwback from the very early days when I first wrote the compiler from scratch back in the very early 2000s, and is something I will be getting into when time permits, but it is a "biggy", so I cannot just jump into it, because of the fragmented RAM of the 8-bit devices and the specific locations that certain compiler system variables and bit variables must reside in. Unfortunately, I made the language too flexible, so variables could be created anywhere, unlike most other languages that have specific locations in a listing for variables and constants etc...

Unlike the Positron16 compiler that compiles for devices with linear RAM, so I wrote the compiler's variable code using a better method, because I had learned a lot more about compiler creation in the 10 years, or so, between writing the 8-bit and 16-bit compilers. With Positron16, it does not matter if a variable is created before or after it is used.

[John Lawton]

Ooh-er I hadn't realised that variables could be encountered in the code before being defined, I always define variables very near the beginning of code. So what is the default definition, a byte?

If a variable was encountered in the code but hadn't been previously defined, then I had previously assumed that compilation would be aborted.

I can see how complex a matter it is for the compiler when variables can be DIMmed in Procedures as well as in the main listing of variables.

Unfortunately it seems flexibility can give rise to 'loose' programming practices and sometimes unexpected behaviours.

John

[top204]

The compiler will default to an unsigned Byte variable.

[Wimax]

I thank you all for your valuable advice!

I have always used directories dedicated to individual projects, but only saved the .bas file there. Now I know that I can easily solve by copying the libraries used in the main programme into the same directory also so as not to affect the original ones.

[joesaliba]

Les,

All variables in include files where included before the variable is being used.

However, I noticed that, although the compiler issued no warning or errors and compiled, some DIM variables included in various include files where not being loaded when required to do so.

One particular include worked as expected, but when I added more include files, variables just stopped working.

As a workaround, I took out all DIM from various include files, included them in another include file, and placed this at the beginning of code.

At least for this particular code I worked like this. It is not very common for me to use too much includes, which BTW, they are only about 5 includes.

I remember I opened a thread about this some months ago and hadn't any solvable feedback, hence I went with the route mentioned above.

Joe

[RGV250]

Hi,
I am a bit confused by this.

In the Positron8 compiler, a variable used in a program before its Dim creates it will not always be correctly identified as the correct type

Surely the compiler gives an error Item xxx not found if a variable is not Dimmed?.

I wonder if it is meant to say the Dim statement has not defined the variable type?

The compiler will default to an unsigned Byte variable.

I tried a simple test and it appeared to be a word type?

Code Select Expand

    Dim Temperature_Temp ' As Dword
    Dim Temperature_Temp_B0 As Temperature_Temp.Byte0 'Alias unsigned Part1 to the low byte
    Dim Temperature_Temp_B1 As Temperature_Temp.Byte1 'Alias unsigned Part2 to the 2nd byte
    Dim Temperature_Temp_B2 As Temperature_Temp.Byte2 'Alias unsigned Part3 to the 3rd byte
    Dim Temperature_Temp_B3 As Temperature_Temp.Byte3 'Alias unsigned Part3 to the high (4th) byte    I commented the As Dword and compiled and got an error "Item Byte2 not found?

Regards,
Bob

[John Lawton]

I think the compiler is being a bit clever as if you code:

Dim test_var

It produces the same assembly as does:

Dim test_var As Byte

John

EDIT: Ignore the above, I was wrong!

[Stephen Moss]

All variables in include files where included before the variable is being used.

Where the variable are only used in the include file I would not expect there to be a problem.
However, where it may be an issue is if you use the variable in you main program expecting it to work as it has been dimmed in an used include file, but it has been is placed in the main program before the include file.
Then I think the compiler will see the variable before it sees its Dim statement and so may not really know what it is or to do with it, which could cause a problem.

However, I noticed that, although the compiler issued no warning or errors and compiled, some DIM variables included in various include files where not being loaded when required to do so.

One particular include worked as expected, but when I added more include files, variables just stopped working.

I guess only Les would know for certain if the compiler can cope with this or it this would be an issue, but think one problem with using include files it that occasionally (particularly when some time has passed between writing them) you can end up using the same variable name either in multiple includes or an include and the main .BAS file, which can potentially result in a program having multiple DIM declarations for the same variable name without realising it as it may be something some people wouldn't think to check for.

If you use those includes in the same program I don't now how the compiler deals with that, but it could potentially result in the following problems...

• Data corruption as separate parts of the program are trying to use the same variable for different data
• Incorrect memory allocation if each DIM declaration defines the same variable as being of a different sizes/type size as the compiler could then be assigning all instances of the variable to either the first or last instance of its DIM declaration.
• Even if the compiler does try to separate the different DIM declares for the same variable name and store them in different address there is still the possibility that it could be confused at times over which location it should be using for a particular instruction resulting in data being loaded/read from the wrong location.

Either of which have the potential to cause the program to crash or behave oddly, thus if you have not already done so it may be worth checking (expand them in code explorer) that between all the files which combine to make the program there are not multiple DIM declares for the same variable name in case that is causing a problem.

[RGV250]

I think the compiler is being a bit clever as if you code:

Dim test_var

It produces the same assembly as does:

Dim test_var As Byte

Strange as in mine if I do

Include "amicus18.inc"

    Dim Test_Var

I get

; STANDARD VARIABLES
Test_Var equ 0x00
Test_VarH equ 0x01

Confused.Bob

[John Lawton]

Hi Bob,

yes, you are quite right it does.

I don't know what I did but I take back what I said before!

That's what Les calls a querk (a quirk).

John

[RGV250]

Hi,
It is all a bit irrelevant in my opinion as if you do not declare the variable sizes in the first place you have only got yourself to blame when it does not work as planned. Pretty much like accepting the power on defaults for SFR's.

Bob