 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Building MMBASIC with XC32 v1.40
| Author | Message | ||||
| piclover Senior Member  Joined: 14/06/2015 Location: FrancePosts: 134 |
I just downloaded and tried the XC32 v1.40 compiler to rebuild MMBASIC for the Micromite MKII (PIC32MX170, MMBASIC v4.6B), but it fails because the new XC32 version doesn't provide any more the plib.h file and associated library... I tried to get it to work with the new Harmony framework, but it doesn't either got any plib.h file. Did anyone manage to get the new XC32 v1.40 compiler to build MMBASIC, if if yes, how, please ? |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Silly me... There's a link to "Peripheral Libraries (plibs) - Not recommended for new designs" at the very bottom of the download section for XC32 compilers... And yet, I was sure I had my glasses on the nose when I browsed that page, last time... 8-P Anyway, XC32 v1.40 is kind of disappointing when compared to v1.34: it produces a slightly slower MMBASIC... |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
MMBasic is built using V1.33 which can still be downloaded from the Microchip website. I would recommend using that as all testing is done with that version and subtle differences may occur with a later version. Note that it needs to be the professional version. If you do not use that you will not be able to use the optimisations and you will have less program space. Geoff Geoff Graham - http://geoffg.net |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Well, I already paid MicroChip for a PIC Kit3; I'm paying them each time I'm buying a new PIC; I don't see why I would pay 1000+ Euros (!!!???!!) for a PRO version of their XC32 (or XC16) compiler, especially seeing that this compiler is nothing more than an adaptation of an Open Source, GPL licensed compiler, namely, gcc... I therefore downloaded the sources of "their" xc32-gcc compiler from *their* site, and recompiled it (not a task for the faint-hearted !) after having removed the license checking stuff (after all, it's GPL, and everyone is therefore entitled to modify the sources as they see fit !)... As a hint, just do a 'grep -r LICENSE_MANAGER *' in the source tree, and you will already be half-way to removing annoying stuff from this GPLed software... 
So, I'm now the proud owner of a (free but nonetheless perfectly legal) xc32-gcc v1.34 compiler with all gcc optimizations available... I experimented a bit, and while I'm sure you already found new ways around speed and size optimizations in order to manage making MMBASIC v4.7 fit the same memory space as v4.6b, here are my findings: - Some C library functions and MMBASIC/Micromite inlined functions get uselessly linked into the final object: using -ffunction-sections in x32-gcc options and --gc-sections in x32-ld options reduces the final object size by almost 3Kb without any impact on performances or functionality (it's just some dead code removed from the final object). - The whole full screen editor (Editor.c, Editor.h) stuff deserves being compiled as a mips16 object (just use __attribute__((mips16)) before each C function declaration and definition), which leads to slower full screen editor code but this won't be noticeable and it doesn't slow down the actual BASIC program (just its real-time, interactive editing by the user). This, again, saves 3.3Kb or memory in the final object. In my patched version of MM-BASIC, I also made the whole full screen editor code inclusion dependent on a define in Editor.h, meaning I can remove that code entirely if I need more space for custom commands/functions in a project (then simply using AUTOSAVE or Xmodem to download the program into the Micromite). - In the same spirit as for the editor (making non-speed-critical code smaller), I turned the LoadOptions(), ResetAllFlash(), SaveOptions() (Flash.h, Flash.c) into mips16 code, since their speed is totally non-critical (they are executed only once, respectively at startup, on reset, or when the used enters a persistent OPTION, which is normally only done from the command line). - The -fweb optimization allows to gain 64 bytes (as well as some speed, but it's so tiny a speed difference that it's not practically measurable). - The above size optimizations allowed me to use the -ftree-vectorize optimization, which costs about 2Kb of code size, but induces a slight (i.e. just barely measurable) speed optimization. Also, I'm using Linux, and found the following issues when I tried to compile your (untouched) sources: - In Source/Main.c, the '#include "MMBasic\MMBasic_Includes.h"' line shall read '#include "MMBasic/MMBasic_Includes.h"'; gcc will properly translate "/" directory separators into "\" under Windows/DOS, but the other way around is not true, especially since the backslash is, in C, an escaping character used to represent non-printable/control characters such as '\n', '\r', '\t', etc... - In Source/Hardware_Includes.h, '#include "Xmodem.h"', shall read '#include "XModem.h"' (file names are case sensitive on about any current OS excepted DOS/Windows). - The same issue with "\" against "/" directory separators exists in Source/Micromite MX170.X/nbproject/configurations.xml, but I doubt this can be "fixed" without breaking compilation under Windows (this XML file being generated by MPLAB IDE itself): not a big deal (just a matter of replacing all '\' with '/' in an editor), but perhaps worth a mention in the README.txt file... |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8603 |
piclover Be careful with 1.34 it has bugs in strange places e.g. the trig functions in the library are incorrect. It is, right click the editor source file and you will see the whole file is set as mips16. Any file with this sort of override is shown in bold in the file list (Geoff taught me this one) Well done on the compilation of the compiler - excellent work  |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
[quote]It is, right click the editor source file and you will see the whole file is set as mips16. Any file with this sort of override is shown in bold in the file list (Geoff taught me this one)Well, it was not in my sources tree (downloaded from Geoff's site), and it's best having this sort of optimization clearly written down into the source files (via gcc's __attribute__ macro), so that whichever tool you will use to compile them (be it MPLAB's IDE, or just the command line), the optimization will actually make its way to the final binary... |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
[quote]Be careful with 1.34 it has bugs in strange places e.g. the trig functions in the library are incorrect.[/quote]Do you have any pointer(s) to corresponding bug report(s) ? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8603 |
No just stuff I found so I gave up on it and went back to 1.33. Probably library issues rather than the compiler itself This gives problems on 4.7b8 but the xc32-gcc change definitely helps (2K) I'm using the 4.7 project file from Geoff - this has lots of size specific enhancements, also try -minterlink-compressed on xc32-gcc. I don't think he has put this version up yet as it is still beta. |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
This gives problems on 4.7b8 but the xc32-gcc change definitely helps (2K) [/quote]What kind of problem ?... It simply removes the sections that have not be linked to (i.e. that have not been 'consumed' by any of the object files). The gcc part (-ffunction-sections) of this optimization simply ensures that each function is put its in own section, so that ld can eliminate non-called functions individually when it performs the garbage collection (--gc-sections). It is strange that you see an improvement in the final object size if only the -ffunction-sections is used... Perhaps --gc-sections was already there (in one of those per-file overrides of MPLAB) and adding another is what causes your problem... No, I could not find any newer sources than v4.6b. [quote]also try -minterlink-compressed on xc32-gcc.[/quote]It only saves 4 bytes for me, but perhaps Geoff used much more mips16 sections than just the full screen editor and three functions in Flash.c... In which case, v4.7 will be much slower than v4.6, I'm afraid. |
||||
 Print this page |
