Well Done

[TimB]

I'm not interested in speed code comparisons with Proton as there 2 different products however once challenged...

I took the Proton code changed 2 lines to remove the AND comparison and make it 2 If lines. Turned on the OPTIMISER as it is in SF and ran the code.

ROM Used 146
RAM Used 6
Execution Time (us) 77.2

Using the Usart to output the data

ROM Used 356
RAM Used 19
Execution Time (us) 1228.8

What might be forgotten is every time I hit the compile button I look at the asm to see what it produced. I have always been impressed with SF and found a lot of areas that betters Proton. I do not have a favourite and as you know have invested time and money into SF to improve it. Not something I would do for any other product.

[David Barker]

> I'm not interested in speed code comparisons with Proton as
> there 2 different products however once challenged...

I just I enabled the optimiser in PROTON (level 6), with the SAME sample code and got a reduction in ROM to 170 and 92.2us. The equivilant Swordfish program has 181 ROM and 80.2us.

PROTON (with optimiser enabled) has smaller code but still executes (marginally) slower, even with the parameter passing used in Swordfish. I also enabled the optimiser (level 6) in the third I2C sample set and got the following

Swordfish ROM = 265, 4819.6us
PROTON ROM = 350, 4930.4us

I have to say I really didn't want this discussion to become a face off between two compilers, but these discussions do tend to end up this way. I am very well aware of excellent ASM produced by PROTON. The tests shown on the wiki clearly show PROTON does outperform Swordfish in different areas on different tests. I certainly have not attempted to hide this in any way.

However, I think your posts do suggest that a structured approach to programming somehow compromises the efficiency of the code generated, in terms of both code size and execution speed, when compared to a 'flat' approach. I am just trying to show, with clear examples, that this is not always the case.

> I took the Proton code changed 2 lines to remove the AND
> comparison and make it 2 If lines...

This isn't comparing like with like! Perhaps you should re-phrase your statement to 'all code written flat will be smaller, if and only if it is written in a certain way'.

[TimB]

This isn't comparing like with like!.... only if it is written in a certain way"

I agree, any way I'm no longer going to do comparisons with other compilers as that was not the point of my comments.

So I wrote it flat in SF.

Result (code size only) 145 which BTW beats all others I think

Please correct the code If I got it wrong

Code: Select all

Dim Ok As Boolean
Dim Value As Byte
Dim Result As Word
Dim index As Byte
Dim Timer As TMR1L.AsWord

Sub Encode()
   Result = 0
   For index = 0 To 7
      If Value.0 = 0 Then
         Result.14 = 1
      Else
         Result.15 = 1
      EndIf
      If index < 7 Then
	      Result = Result >> 2
      EndIf
      Value = Value >> 1
   Next
   End Sub
   
Sub Decode()
   For index = 0 To 7
      If Result.1 = 0 And Result.0 = 1 Then
         Value.7 = 0
      ElseIf Result.1 = 1 And Result.0 = 0 Then
	     Value.7 = 1
	  Else
	     Ok = false
		 Exit
      EndIf

      Result = Result >> 2
      If index < 7 Then
         Value = Value >> 1
      EndIf
    Next
    End Sub
           
// output results...


Timer = 0  
PIE1.0 = 1
T1CON.0 = 1
Value = 210
Encode()
Decode()
T1CON.0 = 0
End

[TimB]

BTW I will no longer say a Flat language is smaller etc. Just code written flat is smaller.

[TimB]

Hi Dave

This thread has riled me not because I think some other compiler is better but because you think that's what I was trying to say. I was not!

I think SF is *^&** brilliant.

There I hope you understand now!

[gramo]

With all the support Tim gives on the PDS site, the above statement really seals the deal with SF for me