when 128k is not enough

[richard]

updated files and arduino mega328 version too , there were some minor errors but the results are unaffected

arduino int latency 10.75uS code size 1794 bytes

[HenrikOlsson]

Hi Richard,
I started writing a reply based on the previous files you posted, in which I found what looked to me quite substantial differences but now you've changed them so I'm just going to ask instead.
Are all three versions functionally equivalent, ie. are they doing exactly the same thing?

It still looks to me as if there are functional differences between the C version and the PBP version - I'm only comparing the versions for PIC, haven't looked at the Arduino code. It's my understandning that the follwing two snippets should be functionally equivallent:
C-version:

while (1){
     if (d_mode)
     pins_on=va+vb;
     else
     pins_on=vc+vd  ;
    for (x=0;x<5;x++){
        latc =   latc | pins_on  ;
        delay_ms(200);
        latc =   latc & all_off ;
        delay_ms(200);
        }
    if (!d_mode)  shuffle();
       d_mode= !d_mode;
 }

PBP-version:

action:
  pins_on=a+b
  for x = 1 to 5
    latC =   latC | pins_on
    pause 200
    latC =   latC & all_off
     pause 200
   next x

   gosub shuffle
  
   goto action

In the C version there's a d_mode variable which you're checking, I don't see that in the PBP version - what am I missing. (I truly suck at reading C code!)
It won't have an impact on the Interrupt latency (at least not for PBP) but if we're comparing compiles size we're going to have to make the code as functionally equal as possible or the results won't say much, no matter which way it swings.

/Henrik.

[richard]

they are now . I had a few copy paste errors where the second delay fell off the c version and the pbp still had a unnecessary loop in it as well as the led initialising to 0 line misplaced into the loop .I just saw the leds flashing and assumed all was equal . the outcome is largely unaffected anyway . I was really just quantifying the interrupt latency for my own edification , I still don't think the code size comparison is valid a fairer test probably needs a few serout2's and a lcdout and a onwire or two to be meaningful .
the mikro c is now 193 bytes and the pbp 315 other than

[richard]

In the C version there's a d_mode variable which you're checking

your right of course
that's the way I eliminated the redundant loop in the c version
looks like I skipped that step for pbp

code size now 336 and functional equivalence restored
thanks for noticing that

*  Name    : UNTITLED.BAS                                      *
'*  Author  : [select VIEW...EDITOR OPTIONS]                    *
'*  Notice  : Copyright (c) 2014 [select VIEW...EDITOR OPTIONS] *
'*          : All Rights Reserved                               *
'*  Date    : 29/11/2014                                        *
'*  Version : 1.0                                               *
'*  Notes   :                                                   *
'*          :   pic12f1822                                                *
'****************************************************************
#CONFIG
cfg1 = _FOSC_INTOSC
cfg1&= _WDTE_ON
cfg1&= _PWRTE_OFF
cfg1&= _MCLRE_ON
cfg1&= _CP_OFF
cfg1&= _CPD_OFF
cfg1&= _BOREN_ON
cfg1&= _CLKOUTEN_OFF
cfg1&= _IESO_ON
cfg1&= _FCMEN_ON
  __CONFIG _CONFIG1, cfg1

cfg2 = _WRT_OFF
cfg2&= _PLLEN_OFF
cfg2&= _STVREN_ON
cfg2&= _BORV_19
cfg2&= _LVP_OFF
  __CONFIG _CONFIG2, cfg2

#ENDCONFIG
 
DEFINE OSC 8 

include "dt_ints-14.bas"
include "REENTERPBP.bas"
asm
INT_LIST macro
      INT_HANDLER  INT_INT, _TL, PBP,yes
      endm
      INT_CREATE
      INT_ENABLE INT_INT
ENDASM
    osccon=$70    '8 mhz
    anselA=0        'dig i/o 
    ANSELC=0
    TRISC= %11110000
    TRISA= %011111
    APFCON0.7=0
     OPTION_REG.6=0
  a  var  byte
  b  var  byte
  c  var  byte
  d  var  byte
  pin_mode var bit
  d_mode var bit
  x var byte
  all_off var byte
  
  pins_on var byte
  led var lata.5
 
  
  
  
  a=1        ;portC.0
  b=2         ;portC.1
  c=4         ;portC.2
  d=8         ;portC.3
  pin_mode=0
  d_mode=1
  all_off=~(a+b+c+d)
   led=0
  latC =   latC & all_off
  
 action:
  if d_mode then
  pins_on=a+b
  else
  pins_on=c+d
  endif
    
  for x = 1 to 5
  latC =   latC | pins_on
   
  

  pause 200

  latC =   latC & all_off
  
  pause 200

  next x
  if !d_mode  then  gosub shuffle
     d_mode= !d_mode
  goto action
  
   shuffle :
   pin_mode = not pin_mode
  if pin_mode then
  swap a,d
  swap b,c
  else
  swap b ,d
  swap c ,d
  endif
  return
  
TL:
 led=!led 
@ INT_RETURN

[Ioannis]

Richard,

since you do not have PBP variables in ISR, you can set this:

INT_HANDLER  INT_INT, _TL, PBP,yes

as this:

INT_HANDLER  INT_INT, _TL, ASM,yes

and see the difference.

Ioannis

[richard]

INT_HANDLER INT_INT, _TL, ASM,yes

int latency now same as or even slightly better than c around 16-20uS

but its not always an option

[HenrikOlsson]

No, as long as the C compiler also always handles all needed context saving (ie SFR and "system variables") automatically the fair comparison in this case is to have the handler defined as PBP.

I'm pretty sure that a big chunk of the 336 bytes is comming from DT-INTS and I think that part of the compiled/assembled code will be constant while (and I'm guessing) in the C version, due to the intelligent context switching (as the call it in the MikroC manual), as you add more code to the ISR and/or Main() it'll need to do more context saving/restoring and therefor needs more instructions (=more latency) and more RAM (of course).

I think that DT-INTS always saves everything, for good and bad - obviously.

As I stated earlier, comparing these things isn't easy and is never going to be exactly fair.

[richard]

I have notice the c latency can be as low as 4us I first thought that was a glitch but it happens fairly often now that I'm looking , so the odds are that increased complexity in the isr will spread the range further.

there is a thing called chipkit-pi a pic 32(28 pin dip) clone of the arduino , its designed to plug directly into a raspberry pi and has a free ide based on the arduino ide . it has some limited arduino library compatability .
that's my next toy , perhaps thats the step up past 128k ,midrange c gets you nowhere extra in that regard