No specific project in mind; just hoping it's possible to link with pre-compiled binaries to take advantage of existing third-party libraries and/or avoid code translation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes you can. We have converters that support injestion of external data etc.
I have included in the build examples of bmp, jpg and text files but the same process can be adapted to injest any external source. It needs a converter and it could br as simple as an AWK script.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for trying to help, Anobium. But, converting data files is quite different from linking to pre-compiled binaries.
For example, FreeBasic allows one to "Add a library file to linker's list" with the "-l < name >" switch, or various compiler directives. FreePascal, also, provides for the use of libraries with compiler directives and command-line options. And then there's GCC ...
There seems to be no such mechanism in GCBASIC making it essentially a closed development environment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"There seems to be no such mechanism in GCBASIC making it essentially a closed development environment."
GCBASIC is definitely not a closed development environment, but it is also not a true compiler in the sense of the examples you quoted. To start with the two examples you quoted generate programs that require an operating system to run and are essentially linked at runtime. GCBASIC output targets devices from two (up until yesterday) very separate companies and there is no common operating system for them to link with.
GCBASIC uses no binary objects at all, not even for the core compiler. All libraries, core, peripheral and user generated are stored and used in source format. When you "compile" a GCBASIC program it reads all of the source, for each library, in conjunction with the user code and any inline assembler the user has generated. It then outputs an assembly language file in the Language of the Target Device. That file is then passed to the appropriate Assembler, supplied by the device manufacturer, not written as part of GCBASIC.
What you are requesting is not beyond the realms of possibility, but it would require a radical rewrite of the structure of GCBASIC, involve the use of Prototypes in the preprocessor, the generation of custom linker scripts and the maintenance of some kind of object manager to ensure that an AVR object is not linked to a PIC target and visa versa.
To my mind Libraries that are supplied as OBJ only files and need linking in at Build time is more of a Closed Development Environment than one where all Libraries are supplied in source format and are readable, extensible and modifiable.
Cheers
Chris
EDIT: Spelling :)
Last edit: Chris Roper 2016-01-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The examples I gave were only for examples of compiler option syntax regardless of the target machine, making the requirement of an operating system irrelavent. And, while it is true that libraries are essentially linked at runtime, object files are linked at compile time.
There are libraries written in C/C++ that target the two microcontrollers supported by GCBASIC. They could be pre-compiled into either object files or static/dynamic libraries and linked appropriately, if that functionality were provided and the libraries were properly targetted. It seems this would be much easier than having to painstakingly translate any such library to GCBASIC.
I never intimated that I was referring to libraries supplied as OBJ only files when I concluded that GCBASIC is a closed development environment.
Being able to use libraries written in another language is, to me, an open development environment. Conversely, the requirement to have all libraries written in, or translated to, GCBASIC in order to be used, again to me, is not.
I guess it boils down to how we define Open/Closed Development Environment. And, perhaps the definition I used is not completely accurate given that GCBASIC is open-source.
What you are requesting is not beyond the realms of possibility, but it would require a radical rewrite of the structure of GCBASIC, involve the use of Prototypes in the preprocessor, the generation of custom linker scripts and the maintenance of some kind of object manager to ensure that an AVR object is not linked to a PIC target and visa versa.
Well, I wasn't really requesting anything other than information regarding whether or not such linking was possible. Apparently, "possible" is relative ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"There are libraries written in C/C++ that target the two microcontrollers supported by GCBASIC. They could be pre-compiled into either object files or static/dynamic libraries and linked appropriately, if that functionality were provided and the libraries were properly targetted. It seems this would be much easier than having to painstakingly translate any such library to GCBASIC."
If you have the source and the relevant compilers for the libraries you are interested in then there is nothing to prevent you compiling them to Assembler rather than OBJ and then copy/paste the Assembler output into your GCBASIC code.
That is pretty much in line with your comment "if that functionality were provided and the libraries were properly targetted."
The only libraries that I can think of off hand are the ARDUINO and the MPLAB Code Configurator .
Having worked on the CHIPKit project I can assure you that trying to port the ARDUINO Libraries between compilers, even when both compilers where GCC, is not an easy task. Those libraries were not written to be portable.
The Microchip Code Configurator is also extremely difficult to extract individual library functions out of and the effort is pointless in terms of the Microchip Licensing restrictions.
Do you have any examples of the sort of Libraries you have in mind and if possible a link to the repositories?
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The answer, to my original question of whether it is possible to link with external objects is, obviously, no. However, if the topic is interfacing with external libraries, then the issue becomes more one of practicality.
From your statement, Chris, that it would require a radical rewrite of the structure of GCBASIC to accomplish linking of external objects, it is noted that it is not impossible, but also not practical.
Compiling a library to Assembler and then pasting the assembled code into GCBASIC is a very interesting idea. But is it practical? How would one, for example, declare entry points for the functions defined in the assembled code?
Regarding the sort of libraries I had in mind there was nothing specific, just AVR C/C++ libraries in general. I did have in the back of my mind the various Arduino shields and their attendant libraries. And then there is, for example, the library provided by Pololu for their robotics boards: https://github.com/pololu/libpololu-avr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not find any command line option or #inclib compiler directive to link with external objects. Is it possible?
Not that i am aware.
What are you trying to achieve? what is the outcome your are looking for?
No specific project in mind; just hoping it's possible to link with pre-compiled binaries to take advantage of existing third-party libraries and/or avoid code translation.
Yes you can. We have converters that support injestion of external data etc.
I have included in the build examples of bmp, jpg and text files but the same process can be adapted to injest any external source. It needs a converter and it could br as simple as an AWK script.
Thank you for trying to help, Anobium. But, converting data files is quite different from linking to pre-compiled binaries.
For example, FreeBasic allows one to "Add a library file to linker's list" with the "-l < name >" switch, or various compiler directives. FreePascal, also, provides for the use of libraries with compiler directives and command-line options. And then there's GCC ...
There seems to be no such mechanism in GCBASIC making it essentially a closed development environment.
"There seems to be no such mechanism in GCBASIC making it essentially a closed development environment."
GCBASIC is definitely not a closed development environment, but it is also not a true compiler in the sense of the examples you quoted. To start with the two examples you quoted generate programs that require an operating system to run and are essentially linked at runtime. GCBASIC output targets devices from two (up until yesterday) very separate companies and there is no common operating system for them to link with.
GCBASIC uses no binary objects at all, not even for the core compiler. All libraries, core, peripheral and user generated are stored and used in source format. When you "compile" a GCBASIC program it reads all of the source, for each library, in conjunction with the user code and any inline assembler the user has generated. It then outputs an assembly language file in the Language of the Target Device. That file is then passed to the appropriate Assembler, supplied by the device manufacturer, not written as part of GCBASIC.
What you are requesting is not beyond the realms of possibility, but it would require a radical rewrite of the structure of GCBASIC, involve the use of Prototypes in the preprocessor, the generation of custom linker scripts and the maintenance of some kind of object manager to ensure that an AVR object is not linked to a PIC target and visa versa.
To my mind Libraries that are supplied as OBJ only files and need linking in at Build time is more of a Closed Development Environment than one where all Libraries are supplied in source format and are readable, extensible and modifiable.
Cheers
Chris
EDIT: Spelling :)
Last edit: Chris Roper 2016-01-16
Thank you for the input, Chris.
The examples I gave were only for examples of compiler option syntax regardless of the target machine, making the requirement of an operating system irrelavent. And, while it is true that libraries are essentially linked at runtime, object files are linked at compile time.
There are libraries written in C/C++ that target the two microcontrollers supported by GCBASIC. They could be pre-compiled into either object files or static/dynamic libraries and linked appropriately, if that functionality were provided and the libraries were properly targetted. It seems this would be much easier than having to painstakingly translate any such library to GCBASIC.
I never intimated that I was referring to libraries supplied as OBJ only files when I concluded that GCBASIC is a closed development environment.
Being able to use libraries written in another language is, to me, an open development environment. Conversely, the requirement to have all libraries written in, or translated to, GCBASIC in order to be used, again to me, is not.
I guess it boils down to how we define Open/Closed Development Environment. And, perhaps the definition I used is not completely accurate given that GCBASIC is open-source.
Well, I wasn't really requesting anything other than information regarding whether or not such linking was possible. Apparently, "possible" is relative ;-)
"There are libraries written in C/C++ that target the two microcontrollers supported by GCBASIC. They could be pre-compiled into either object files or static/dynamic libraries and linked appropriately, if that functionality were provided and the libraries were properly targetted. It seems this would be much easier than having to painstakingly translate any such library to GCBASIC."
If you have the source and the relevant compilers for the libraries you are interested in then there is nothing to prevent you compiling them to Assembler rather than OBJ and then copy/paste the Assembler output into your GCBASIC code.
That is pretty much in line with your comment "if that functionality were provided and the libraries were properly targetted."
The only libraries that I can think of off hand are the ARDUINO and the MPLAB Code Configurator .
Having worked on the CHIPKit project I can assure you that trying to port the ARDUINO Libraries between compilers, even when both compilers where GCC, is not an easy task. Those libraries were not written to be portable.
The Microchip Code Configurator is also extremely difficult to extract individual library functions out of and the effort is pointless in terms of the Microchip Licensing restrictions.
Do you have any examples of the sort of Libraries you have in mind and if possible a link to the repositories?
Cheers
Chris
The answer, to my original question of whether it is possible to link with external objects is, obviously, no. However, if the topic is interfacing with external libraries, then the issue becomes more one of practicality.
From your statement, Chris, that it would require a radical rewrite of the structure of GCBASIC to accomplish linking of external objects, it is noted that it is not impossible, but also not practical.
Compiling a library to Assembler and then pasting the assembled code into GCBASIC is a very interesting idea. But is it practical? How would one, for example, declare entry points for the functions defined in the assembled code?
Regarding the sort of libraries I had in mind there was nothing specific, just AVR C/C++ libraries in general. I did have in the back of my mind the various Arduino shields and their attendant libraries. And then there is, for example, the library provided by Pololu for their robotics boards: https://github.com/pololu/libpololu-avr