Update on procedures in the Proton BASIC Compiler – 338 days old

[top204]

Just an update on the procedure mechanism that I'm creating for the standard 8-bit Proton compiler....

Things are going well.... I've just finished updating the expression parser and procedures are now accepted within expressions:

Device = 16F1937
Declare Xtal = 32

Dim Global_MyFloat as Float

Proc RadToDeg(pRadians as Float), Float

Symbol c180DivPi = 180.0 / 3.14    
     Result = pRadians * c180DivPi 
EndProc

Global_MyFloat = RadToDeg(120) / 2.0

Notice the local Symbol within the procedure. This will not be recognised anywhere else in the program, only within the procedure, but if there is a symbol outside the procedure, the contents will use that, so the code within a procedure can access global types as well. If the same name symbol or variable is used inside and outside (globally) the procedure, the code inside it will use the local symbol or variable, and ignore the global symbol or variable with the same name. i.e. Locals have precedence.

Also, String and Array returns are finished:

Device = 16F1937
Declare Xtal = 32

Dim Global_MyString as String * 32

Proc TestProc(), String * 32
    Result = "Hello World"    
EndProc

Global_MyString = TestProc()

I'm now busy adding the ByRef and BycRef code to the parameters, so indirect access of variables and flash memory can be done. It's equivalent to sending the parameter as the address of a variable, so the Ptr8, Ptr16, or Ptr32 commands can be used. Or the cPtr8, cPtr16, or cPtr32 commands if sending the address of Flash memory. i.e. Data tables.

It's been a struggle adding the procedures, and all that comes with them, in the main body of the compiler, without disturbing the compiler as it stands, but it really is starting to look good, and has been a joy to get back into the programming mode! It should be ready in a couple of weeks, so watch out for, future, true libraries for Proton, the same as Proton24 types.

[johngb]

Will these changes be fully reflected in the P24 version of the compiler? e.g. BycRef.
Hopefully once users have had time to work with procedures in the 8 bit environment they may be more inclined to make the step to 16 bit MPUs.

[top204]

I truly hope so John, because the PIC24 and dsPIC devices are brilliant! They are fast, easy to use, and inexpensive for what they offer. Hopefully then, I'll create Proton32, but, IMO, the PIC32 devices have also not caught on, so I'm also busy making the moves for ProtonAVR. I have a, "very alpha", version of the compiler working with the AT328P device and it looks good. :-)

The PIC24 and dsPIC devices can access Flash memory as they do RAM. It's named PSV memory access. This means the BycRef directive is not required, but I will be adding it to Proton24's syntax, but it will ignore it, and use ByRef instead.

Even the enhanced 14-bit core devices can access Flash memory as they do RAM, by adding 0x8000 to the address. i.e. Bit-15 set. It means the standard FSR0L\H and FSR1L\H SFRs can be used to read Flash on these devices, and the compiler uses this mechanism as standard because it produces very good and tight code. However, the 18F devices and the standard 14-bit core devices, need the flash memory address so they can use the TBLPTRL\H\U SFRs for 18F, or EE SFRs for standard 14-bit core, and different mnemonics to access Flash memory. Hence the need for the BycRef directive to use the address of flash memory, and not the address or RAM when accessing quoted strings of characters. i.e. "Hello World", because these are stored in flash memory and not sent sequentially as most other compilers do, or the name of a data table. i.e. Cdata or Dim as Code, which are both the same, but Dim as Code is newer and better because the compiler will eventually be changed to use only data tables that are accessed in the program, just as Proton24 does now. So many Dim as Code data tables can be placed in the code listing, but only the ones used will be placed in the final compilation.

This is the big problem with writing the compiler to suit all 8-bit devices! They are all very different, but it has to be made as transparent as possible to the end user, and hopefully, Proton does this as much as is possible.

[normnet]

...Hopefully then, I'll create Proton32, but, IMO, the PIC32 devices have also not caught on...

I confess I am presently trying to make headway with PIC32MZ (MZ includes 200MHz) in MPLABX however its been a beast for even some of the most basic commands. MZ example code for DelayMS for instance isn't easily found. I may well of overlooked however I have not as of yet found one definate PIC32MZ code example. I can now after some time blink an LED. PDS PIC32MZ 200 MHz support would be more than welcome. So far it appears the PIC32 lineup may be a bit easier to solder than some of the others including ARM as PIC32 devices include TQFP pins.

Norm

[johngb]

@Les
I wondered if that might be the case after I sent it but it would be good to keep compatibility between compilers if possible.

[towlerg]

Surely ProtonAVR is your way forward commecially.

[GAMBOA]

Les,

I'm glad Proton is progressing properly. Many of us are anxious to be able to buy the new version.
As for PIC32. I think that Microchip has lost the battle against the ARM and I think that this line will be abandoned to join the universal current of the whole world with ARM. In fact, he already has some models with an ARM license in addition to the Atmel that are also his now.

Regards,
Gamboa

[top204]

That's my thoughts as well Gamboa. With Microchip buying Atmel, they now have the ARM licensing, and I think they will move down that avenue, and eventually drop the PIC32 devices, or do as they've done with the older PIC microcontroller's, and increase the prices so much, few people buy them.

I wonder how Microchip are going to deal with the Chinese rip offs of the Atmel devices. i.e. all the ones used in the Chinese Arduino boards that cost a lot less than the chips themselves when bought from Microchip, or anywhere else, even when bought in bulk? They seem to be Chinese fabrications of the devices, so Atmel must have been quite freelance with their architecture specs.

[normnet]

Going the Microchip ARM route the SAM E70/S70/V70/V71 Family offers up to 300 MHz in as small as a 64 pin LQFP as well as QFP. Impressive specs!

[Oldhack]

Hello
Proton Just gets better and better,.
A very large thank you Les for your dedication, my thought is when will the C++ crowd will wake up and see Proton as the best Compiler out there.
Gary

[fanie]

Thanks Les, same as Gary said above. The whole world is in a terrible shamble, but the good news is it is slowly turning for the better, and so will the processors I suspect.
The same conditions (politically) caused disruptions some 2000 years ago when the zodiac changed from Aries to Pisces, now it's changing from Pisces to Aquarius - the up side is we now have pics ;-)

The 5th Dimension Age of Aquarius 1969

The Age of Aquarius: What it REALLY Means

[charliecoultas]

Good work Les. You know how much we all appreciate your fabulous work on the compiler, it just keeps getting better and better. Happy New Year to you and everybody.

Charlie