10fxx support......

[Niki]

Looks interesting. Please keep us updated with this project.

Will do! For reference, it's a recursive descent compiler where the grammer is built/modified at run-time. Modules (same as mB procedures) can also have their own BNF grammer which can make things interesting.

The core system is MPU independant (it just does SELECT * FROM mpu_commands where mpu='[target processor]' to the database) & builds with what it can find. Will be adding Coldfire processor support next.

[LGR]

I'm curious. I understand writing a very limited compiler for the PIC 10F, for very limited applications. But the Coldfire is at the opposite end of the scale. It's able to do anything a PIC24 can do. Will the language be expanded for that, or fo you simply have a specific use for a limited language on Coldfire?

[Niki]

I'm curious. I understand writing a very limited compiler for the PIC 10F, for very limited applications. But the Coldfire is at the opposite end of the scale. It's able to do anything a PIC24 can do. Will the language be expanded for that, or fo you simply have a specific use for a limited language on Coldfire?

Who said it would be limited? The hardware stack limitation on the 10F was fairly easy to solve. The compiler can replace Gosub's with Goto's or even direct PC manipulation.

It would only be features like enumerations that would be missing for 10F.

[zristic]

The compiler can replace Gosub's with Goto's or even direct PC manipulation.

Be careful. Gosub has the pair command "Return" which returns the program flow to the first instruction after "Gosub". Now, if you replace "Gosub" with "Goto", then "Return" will have no information where to direct program flow.

[Niki]

The compiler can replace Gosub's with Goto's or even direct PC manipulation.

Be careful. Gosub has the pair command "Return" which returns the program flow to the first instruction after "Gosub". Now, if you replace "Gosub" with "Goto", then "Return" will have no information where to direct program flow.

Yes, a program with multiple Gosub's to the same routine can't be replaced by just Goto's., but if the return PC is pushed onto a software stack then you can Goto a routine & "return" via PC manipulation.

Techniques I learned while writing that RTOS system a while back.

[LGR]

Your language syntax is interesting. It reminds me of COBOL, in that the statements resemble English sentences more than other programming languages. I could see a niche for that as a logic programming language for PLC type applications for people who don't want to learn programming. The trick with those types of applications is to give the programmer a way to do non-blocking time delays without forcing them to actually set up interrupt routines. Is that the niche that you had in mind, or am I misreading it?

[Niki]

Your language syntax is interesting. It reminds me of COBOL, in that the statements resemble English sentences more than other programming languages. I could see a niche for that as a logic programming language for PLC type applications for people who don't want to learn programming. The trick with those types of applications is to give the programmer a way to do non-blocking time delays without forcing them to actually set up interrupt routines. Is that the niche that you had in mind, or am I misreading it?

The use of English is mainly to keep a very high level of abstraction *and* to make it easy for non-programmers to use. Everything a PIC (or other mpu) will be available or software emulated (I2C on a 10F!) where appropriate.

Without the abstraction layer, you start requiring mpu specific flags which ruins code portability.

[Niki]

Update: Not far from having a public alpha test version (v0.01) available now.

Nested IF-ELSE-ESLEIF's and WHILE loops are supported (nesting only limited by PIC memory), and simple BYTE variable types are supported. Conditions are currently limited to 'Variable = Variable' or 'Variable = Integer', although this will change when expressions are supported.

Even with thses limitations, you can write custom logic code, or even PWM using TMR0

[Niki]

Another update:

I've managed to include full expression support now

The compiler converts all expressions to Reverse Polish Notation (A retlw table in PICs) and includes an RPN stack calculator to work it out.

This method is about half the speed of mB's inline approach, but allows for greater code compression on larger (or repeated) expressions.


zristic: Ok, creating a compiler is a lot of hard work

[zristic]

zristic: Ok, creating a compiler is a lot of hard work

He, he, just waiting to test it

[Niki]

zristic: Ok, creating a compiler is a lot of hard work

He, he, just waiting to test it

Surely you mean "break it"

Not long now.. Hopefully within the next 2-3 weeks.

[zristic]

When is the version going to be released?

[Niki]

When is the version going to be released?

Took me 8 days to implement expressions & 20 minutes to turn it into a 2-pass compiler..

If I may ask, what advantages/disadvantages did you find with implementing your own assembler in mB?

[zristic]

If I may ask, what advantages/disadvantages did you find with implementing your own assembler in mB?

It is not our own asm, it is much like mchip's asm, just that the names of variables are longer and clearer, for the sake of Easier reading/debugging.

Btw, after you release the first version, when is the next one going to get out?

[Niki]

If I may ask, what advantages/disadvantages did you find with implementing your own assembler in mB?

It is not our own asm, it is much like mchip's asm, just that the names of variables are longer and clearer, for the sake of Easier reading/debugging.

Btw, after you release the first version, when is the next one going to get out?

I meant advantages of embedding your assembler into the IDE instead of using MpAsm as the back-end..