Version 3 Assembler - confused

[canipus]

I've been comparing v2 with the new v3 demo and I am somewhat perplexed about the assembler part of the compilation. v2 used MPLAB's windows assembler but v3 doesn't. I understand about the change in the compiler being susperior and functionally more advanced, BUT surely the assembler routines can't be more advanced than that produced by MicroChip? They make the PICs so their Assembler function should be the reference assembler. I can't see from the Compiler options window how to set up the path to point to the MPASMWIN plus the INCLUDES line? Does this mean there is now no way of going direct from Flowcode chart to HEX code via MPASMWIN? Sure I can see you could just create assembler code, then port that into MPLAB and do the assembler function there; but not being able to do this in one operation would seem a major backward step. You would have to convince me that the Assembler routines built in to the new Compiler function are at least as good as Microchips before I would accept that MPASMWIN is now truly redundant.

Am I missing something? Is it possible to set up the new Flowcode to use MPASMWIN (and pick up the include files), after the pre processor and compiler have done what they need to do?

[Steve]

Hello canipus,

The underlying C compiler that Flowcode v2 uses converts C code to Assembly, which is then assembled using MPASMWIN to create the HEX file.

V3 uses a different C compiler that generates the HEX file directly from the C file, but also produces an Assembly file. I would guess that this produces more optimized code.

You cannot set Flowcode v3 to use MPASMWIN unless you change the C compiler setting as well. And doing this may mean that some of the components do not compile.

I would suggest you give it a try. We've been using this compiler for a while now and have had no problems with the in-built assembler.

[canipus]

V3 uses a different C compiler that generates the HEX file directly from the C file, but also produces an Assembly file.

Steve
So the new compiler goes straight from C to object code (Intel Hex)? And then it takes the HEX file to disassemble it to produce an Assembly file?

Isn't the disassembly process sort of backwards and I didn't know it was possible to go straight from C to object code?

thanks for the response
canipus

[Steve]

canipus,

I'm not sure exactly what the compiler/linker does internally, but it takes a C file and produces an ASM file, a HEX file and a load of other files that can be used for debugging purposes. And it does all of this without the need for an assembler such as MPASM.

If I find out any more, I'll let you know.

[canipus]

canipus,

I'm not sure exactly what the compiler/linker does internally, but it takes a C file and produces an ASM file, a HEX file and a load of other files that can be used for debugging purposes. And it does all of this without the need for an assembler such as MPASM.

If I find out any more, I'll let you know.

Steve

With respect the way it looks to me that inspite of the incredible wonderful improvements in v3, you have implemented the new compiler so that users can no longer incorporate the Microchip Assembler at the time of compilation but only as an after event. That has to be a negative for anyone looking at Flowcode as a quick proof first concept development tool. The Microchip Assembler IS the reference Assembler and you have implemented a new compilation process that negates its use.

With reference to your earlier reply can you please give me the settings that shows how you can set up the v3 options to use the original compiler and the MPASM assembler? I cannot see how or where you would put the path to the INCLUDE files that would be required. I want to check that v3 can still compile and assemble using the v2 components.
regards

canipus

[Dave]

Behind the scenes Flowcode 3 uses the BoostC compiler from SourceBoost Technologies (http://www.sourceboost.com). The BoostC compiler goes from C code to a .hex (intel hex) file, that is one that you can download using your device programming hardware and software.

The advantage of not using MPASM is that there is no longer a dependancy on it. It MPASM doesn't have to be installed to use FlowCode 3. A layer of complexity has been removed.

The code produce by BoostC is no better than that produce by MPASM fed with an assembly file that has all the required instructions in it (they both have the same instruction set to play with).

In fact BoostC creates a .asm file for those people who would like to assemble the code using MPASM . You can assemble this code with MPASM and you will get exactly the same .hex file contents that BoostC generates.

Have a look in .asm , .casm and .lst produced during a compilation.

I hope that helps.

Regards
Dave

[canipus]

Behind the scenes Flowcode 3 uses the BoostC compiler from SourceBoost Technologies (http://www.sourceboost.com). The BoostC compiler goes from C code to a .hex (intel hex) file, that is one that you can download using your device programming hardware and software.

The advantage of not using MPASM is that there is no longer a dependancy on it. It MPASM doesn't have to be installed to use FlowCode 3. A layer of complexity has been removed.

The code produce by BoostC is no better than that produce by MPASM fed with an assembly file that has all the required instructions in it (they both have the same instruction set to play with).

In fact BoostC creates a .asm file for those people who would like to assemble the code using MPASM . You can assemble this code with MPASM and you will get exactly the same .hex file contents that BoostC generates.

Have a look in .asm , .casm and .lst produced during a compilation.

I hope that helps.

Regards
Dave

Dave,

Thanks for the response. I am actually aware what you outlined but I think perhaps the importance of my point is being missed, probably because I failed to express it correctly.

I am concerned about the elimination of the Microchip product from the equation. You, and presumably Matrix M. see it as a layer of complexity being removed. THAT is the problem! What you perceive as complexity, others like myself see as an 'insurance value' an absolute prerequisite requirement.

Let me explain further. The reliablilty of a system is dependent on numerous value components and sub systems. They are too numerous to outline at the of risk digression, but one of them is the quality of code that forms the control function of the PIC. The MPASM is a component directly under the same control as the Company that manufactures the PIC. If the life of the user of the system (PIC and assembled code and developer code) was TOTALLY dependent on the system performing without error e.g. medical diagnostics/automated medication administration; then it makes sense to reduce the legal liability of error. If the PIC component and assembler used, were both produced by Microchip then the statistical liability for failure is moved further into the liability systems and quality systems of a Corporation that has the resources to evaluate and quantify the risks of failure. To extract part of that equation and substitute it with an unknown third part assembler is to change the risk evaluation. Put it another way, if YOUR life depended on my product, assuming that my code was "perfect", would you want the Microchip PIC object code produced by a Microchip product or a third party product? What you see as complexity I see as insurance.

In fairness, its not objective to state that if you compare the object code produced by the two systems, they are identical. You don't know that without running an entire suite of expensive tests to quantify and produce a set of statistics to support that assertion.

I accept you can still take the assembler file and use MPASM but ONLY as an extra step. In version 2 this was not necessary and I see that omission as negative - not a catastrophe - but a nuissance.
It also raise the question how that assembled file is produced. If it is being produced as a disassembled component rather than as part of the forward process engineering, then it raises the issue about the accuracy of the disassembler process. Most of the current disassemblers on the market are far from accurate.

I maintain that Matrix M. have made a blunder by not facilitating the use of the Microchip Assembler as part of the main object code production. It may make things "easier" but not necessarily "secure" in terms of qualitive code production.

[Steve]

canipus,

Personally, I don't see the problem.

If the code going into MPASM is erroneous in any way, then that will severely compromise a system's behaviour. So, having the assembly internal to the C compiler/linker is just as "secure" as producing an ASM file and having it be assembled by MPASM. This is because the C compiler is just as likely to produce 'bad' ASM code as it is to produce a 'bad' HEX file.

The reliability of the code produced by a system is not a combination of the reliability of the individual components within that system. Rather, it is dependent on the way in which the system works as a whole.

[canipus]

canipus,

Personally, I don't see the problem.

If the code going into MPASM is erroneous in any way, then that will severely compromise a system's behaviour. So, having the assembly internal to the C compiler/linker is just as "secure" as producing an ASM file and having it be assembled by MPASM. This is because the C compiler is just as likely to produce 'bad' ASM code as it is to produce a 'bad' HEX file.

The reliability of the code produced by a system is not a combination of the reliability of the individual components within that system. Rather, it is dependent on the way in which the system works as a whole.

Right, but we're not talking about the same assembler in these two cases. In the first case the internal assemble is manufactured by ? and in the second case the outboard assembler is manufactured by Microchip; or are you saying the assembler part of the new C compiler IS the Microchip assembler? ....ah that would explain everthing - and yes in that case there is no problem. I'm under the impression that the new compiler is using a proprietary assembler? Can you confirm?

[Steve]

are you saying the assembler part of the new C compiler IS the Microchip assembler?

Nope, it is not the Microchip assembler.

To clarify things, v2 of Flowcode used a compiler (C2C) that created an ASM file that was then assembled into a HEX file by MPASM. V3 of Flowcode uses a compiler/linker (BoostC/BoostLink) that directly produces a HEX file.

My point is that the ASM file produced by C2C could have errors, which would compromise a system's security/reliability - in which case the HEX file produced by MPASM would also have problems.