Well Done

Bruce · Post by **Bruce** » Fri Feb 23, 2007 1:26 am

Kudos Dave.

Part of my job here is evaluating compilers. Most of them have a considerable number of updates & major issues on the first few releases.

I don't think I've ever seen any compiler, BASIC or otherwise, that had so few issues to start out.

I don't have an enormous amount of time to beat-up on Swordfish, but I can tell you, it's one of the most solid compilers I've ever seen before being this new to the market.

I have compared a lot of code produced by Swordfish to Microchips C18, and for ease-of-use, compact code, flexibility, library support, and reliability, I would have to say you have them beat hands-down.

Not bad considering how long C18 has been out there. Not to mention the cost comparison.

Well done is an understatement...;o}

mister_e · Post by **mister_e** » Fri Feb 23, 2007 2:00 am

I agree with Bruce. I also have tested many different compiler C & Basic and for various Microcontroller brand. BY FAR, Swordfish beat everything else already on the market.

Add PIC24 and DsPIC WOOOHOOOO end of life for few other compiler here

Add the WHOLE PIC family... this will be my only one tool to use... even if i understand it will not happen and for good reasons already discussed before. Let me dream

David Barker · Post by **David Barker** » Fri Feb 23, 2007 4:36 pm

Thanks for the support!

An awful lot of work went into Swordfish and it's really appreciated when people with experience of this type of product take the time to give such positive feedback.

lubo · Post by **lubo** » Wed Feb 28, 2007 8:20 am

Hi mister_e

You wrote :

"I agree with Bruce. I also have tested many different compiler C & Basic and for various Microcontroller brand. BY FAR, Swordfish beat everything else already on the market."

Excuse me ,are you sure, is true what you said ? That's interesting.

Interesting to see and compare the results from different compilers if they compile codes that perform one and the same task.

Please compare the code sizes generated by Swordfish, Proton PDS and CCS for one or more examples by your choice.

Appreciation if you post concrete results here.

Regards

mister_e · Post by **mister_e** » Thu Mar 01, 2007 8:49 pm

Hi Lubo,
Sorry, but i'm not talking about code size, which to me is mostly pointless to compare.

I'm talking about ease of use, reliability, stability, flexibility, amount of bugs/issues etc etc etc, but not the code size.

lubo · Post by **lubo** » Fri Mar 02, 2007 7:29 am

Hi Steve

I think with you about ease of use, reliability, stability, flexibility, amount of bugs/issues, yes it's true.

Using PDS long time and trying Sfordfish now i maintain that the ide is THE BEST.

But, isn't important code size for you? REALLY!If so ,why? I am confused. Explain me , please.

And, what about the speed performance of the generated code?

Aren't the size of a code and its speed performance the most important advantages of a compiler to the others?

Regards

Lubo

David Barker · Post by **David Barker** » Fri Mar 02, 2007 1:47 pm

> But, isn't important code size for you? REALLY!If so ,why? I am
> confused. Explain me , please.
> And, what about the speed performance of the generated code?
> Aren't the size of a code and its speed performance the most
> important advantages of a compiler to the others?

Yes, these things are important.

It is pretty easy to skew test results to show a compiler in a better
light than another. Plus, any forum is biased towards its core user
base.

However, I think it fair to say that in terms of executation speed
and ROM usage, a reasonably well coded Swordfish program can
compete with any other PIC18 compiler on the market.

Here are some figures to support what I've just written...

http://www.sfcompiler.co.uk/wiki/pmwiki ... Comparison

lubo · Post by **lubo** » Fri Mar 02, 2007 3:07 pm

Hi David

Thank you for your reply.

I just forgot to say in my previous post that i expect excellent speed performance of the codes generated by а Sfordfish compiler.

Reading your excellent article i am now convinced in that.

My own experiments give similar results about code size: Sfordfish generate code that is close or a bit larger then Proton PDS code and close or even less then CCS code in some cases.

So that: acceptable code size ,good execution time ,and the best IDE!

Best Regards

JackOfVA · Post by **JackOfVA** » Fri Mar 02, 2007 3:20 pm

Perhaps I can add one data point for your consideration ...

When I started writing the code for my Z90 panadapter early in 2006 using an alpha test copy of Swordfish, my plan was to write parallel versions of the code, one in Swordfish and one in Mikro Pascal. The idea was to provide a comparison of the two compiler code output and to provide a backup to me, should an serious problem develop with Swordfish.

To make this story shorter, I abandoned the Mikro Pascal parallel version after a couple of weeks, as it had too many bugs and missing features to continue the process. When I found that in MP that C =:= A*B did not yield the same answer as C := B*A, I gave up on MP as a usable tool for serious work. I've not looked further at MP, but presumably some of the worst bugs have been fixed and missing features added during the last year.

And, although Swordfish had problems as well, as expected during alpha testing, those problems were fewer than I found in release 5 (if I recall correctly) of MP and those problems I found were quickly fixed.

The resulting program has a code size of about 34K bytes and is several thousand lines of Swordfish.

Jack

Resulting product, the Z90 panadapter can be seen at www.cliftonlaboratories.com.

lubo · Post by **lubo** » Fri Mar 02, 2007 3:41 pm

Hello Jack

The compilers of Mikroelektronika don't stand comparision with Swordfish and Proton at all.

Just their compilers support all pic mikrocontrollers but Swordfish supports 18th serie only.

Regards

BTW , good site.

TimB · Post by **TimB** » Fri Mar 02, 2007 4:34 pm

When doing a comparison of Proton to SF you have to write the code exactly the same way. As an example I'm doing a piece on making library commands in Proton. It's a lengthy business (not like in SF) but the end result is a command that transfers data around in the same way. I then for comparison wrote the same thing in SF. I was amazed that the code was actually smaller.

However Proton as all its commands a integrated into the compiler will produce smaller code than currently SF will, for commands like Print Dec Float. But that's because the SF library was written all in Basic.

Procedural languages are always bigger than flat. But this is known by Dave so he stuck with the 18series which has more code space.

If your worried about the us that the code takes longer to do the job then up the Xtal speed. If the slightly large space that the program fills the Pic then you have written one big program and already reaped the advantages of the structural language and you would have been struggling in a flat language.

SF can do a lot more than Proton and that's a lot for me to say as I use it a lot.

As for comparing it to C well I doubt there will be much difference in code usage.

David Barker · Post by **David Barker** » Fri Mar 02, 2007 5:27 pm

> However Proton as all its commands a integrated into the compiler will
> produce smaller code than currently SF will, for commands like Print
> Dec Float. But that's because the SF library was written all in Basic.

It is certainly true that a built in command such as DEC Float with produce a much smaller code footprint than Swordfish. Built in number conversions handled by printf and dec et al do work very well indeed. However, there are quite a few built in commands in both CCS and PDS that can be handled just as well in a Swordfish Module. The I2C example shown on the Wiki demonstrates this. It is one positive against a negative.

> Procedural languages are always bigger than flat.

This is absolutely not true. Procedural languages are not always bigger. Clearly, if you have many output routines, or number conversions, like those shown in the Wiki examples, then I would agree that such a program could be much, much smaller than a Swordfish implementation. However, PBP is a flat language, yet the Wiki examples clearly show that the code generated is much larger, even when using built in DEC.

In addition, two of the three examples clearly show Swordfish ROM usage which is less than PROTON, which is also a non-procedural language. This is based on code eqivilance. The bottom line is that comparing code usage between a group of quality compilers will ultimately reveal different winners and losers for different code samples. There would never be an ultimate champion. However, the measurements I made clearly demonstrate that procedural languages are NOT always bigger than flat - unless anyone has any evidence otherwise.

> If your worried about the us that the code takes longer to do the job then up
> the Xtal speed. If the slightly large space that the program fills the Pic
> then you have written one big program and already reaped the advantages of
> the structural language and you would have been struggling in a flat language.

I'm not sure I understand this. Are you saying that Swordfish generates larger code and will therefore run more slowly, so just up the xtal speed? If so, against what are you comparing? If it is not what you mean, then perhaps you could explain a little more...

Bruce · Post by **Bruce** » Fri Mar 02, 2007 8:49 pm

> Procedural languages are always bigger than flat.

I would certainly like to see the proof of any argument like this.

TimB · Post by **TimB** » Fri Mar 02, 2007 9:41 pm

Bruce

I would certainly like to see the proof of any argument like this.

Ok here's one.

Code: Select all

    Device 18F452

    Dim VarA As Word
    Dim VarB As Word   
    
    VarA = 1000
    VarB = 2000
    GoSub Addition        
    HRSOut VarA
    Stop
 
Addition:
    VarA = VarA + VarB
    Return

Now in a procedural language you would write

Code: Select all

    Include "usart.bas"

    Function Addition(Pval1 As Word, PVal2 As Word) As Word   
    Dim result As Pval1
    Result = Pval1 + Pval2
    End Function


    Dim VarA As Word
    Dim VarB As Word   
    
    VarA = 1000
    VarB = 2000
    VarA = Addition(VarA,VarB)
           
    Write (VarA)

Straight away you will see if you look at the asm that you have passed VarA and VarB to the subroutine then had to pass the result back.

Before you say you could write the code exactly the same in a procedural language and get the same result I have to point out that you would then have written it flat which is my point.

A hand written routine using the same variables as the subroutine you about to use will always produce smaller code. But is it a nice way to write code? Is it re-usable? Hell no its a very big pain in the ass, and as soon as you start to write large code it becomes very difficult to maintain.

Dave

Yes I am saying code written flat will be smaller. But as I said by the time it become an issue and you would have benefited from the flexibility and modularity that SF has to offer which would have saved you many many hours of work which would far out way any down side.
No I am not saying that you should increase speed of the xtal as 95% of my code runs at 4mhz and I still have time to spare, but as I said if some one considered the us (microsecond) it takes to pass the variables around to much of an issue then put the clock up.

Considering I have spoken many many times with you over the pros and cons of a language and the benefits of SF I'm not sure why your interpreting my comments as being anything but truthful and honest and trying to do nothing but indicate my liking for and admiration for SF.

David Barker · Post by **David Barker** » Fri Mar 02, 2007 10:49 pm

> Yes I am saying code written flat will be smaller... but as I
> said if some one considered the us (microsecond) it takes to
> pass the variables around to much of an issue then put the
> clock up.

I'm sorry but I don't agree. In many cases it will, in others it wont. We can cherry pick code forever, showing the pros and cons of any compiler. However, saying that code written flat will always be smaller and to imply that a procedural languages parameter passing shortcomings should be compensated by increasing the xtal is, in my view, a little outrageous

If you take a look at the code here

http://www.sfcompiler.co.uk/wiki/pmwiki ... hesterCode

you will see that the Swordfish code uses a structured approach (with parameter passing) but the PROTON and PBP versions are written flat. The Swordfish and flat implementations use standard language constructs that can be found in any text book.

The results are here

http://www.sfcompiler.co.uk/wiki/pmwiki ... Comparison

and show that Swordfish executes the code block in 80.4us and takes 181 ROM bytes. The fastest flat implementation takes 106.2us and uses 202 ROM bytes.

Please note that I am NOT suggesting that this will always be the case! It is one specific example. But given your assertion that 'writing flat will always be smaller' and the implication that 'parameter passing is so inifficient you may need to up your xtal', then how do you explain

(a) the difference in execution speed (80us against 106us)
(b) smaller ROM usage

> Considering I have spoken many many times with you
> over the pros and cons of a language and the benefits
> of SF I'm not sure why your interpreting my comments as
> being anything but truthful and honest

Tim, please don't worry - I really don't have a problem with this discussion! I just don't think your case is strong enough to support the assertion that 'all code written flat will be smaller' and that 'parameter passing is inefficient' given the observations I have documented.

I'm just trying to constructively dissagree with you...