Interrupt Procedure...

[PJE]

Hi Pete,

I'm trying to write an interrupt driven input procedure, but I keep getting compiler errors for the function:
interrupt SCI0REC()
begin
while (^SCI0SR & SCI_RDFR)=0 endwhile
sci0rec_buf[sci0rec_iptr] = ^SCI0DR
sci0rec_iptr=(sci0rec_iptr+1) & $F
if (sci0rec_optr=sci0rec_iptr)
sci0rec_optr=(sci0rec_optr+1) & $F
endif
end
What's the correct format for an interrupt function?

Regards,

PJE

[petegray]

Hi PJE,

Like this...

interrupt SCI0REC
begin

i.e. no "()"

Regards,
-Pete.

[PJE]

Hi Pete,

Thanks.

PJE

[PJE]

Hi Pete,

When writing a interrupt function do I need to save/restore the overwritten registers?

My current SCI0 receive code is
interrupt SCI0REC
begin
#asm
LEA (SP)+
MOVE X0,X:(SP)+
MOVE Y0,X:(SP)+
MOVE R2,X:(SP)+
MOVE N,X:(SP)

MOVE #0,X:$0D65 ; Clear reply timer count
MOVE #0,X:TD0count

Start:
MOVE X:$0F02,X0 ; SCI0SR Value
ANDC #$2000,X0
CMP #0,X0
JEQ Start

MOVE #sci0_buf,R2
MOVE X:sci0_iptr,N
MOVE X:$0F03,X0
NOP
MOVE X0,X:(R2+N) ; sci0_buf[sci0_iptr]=^SCI0DR

MOVE X:sci0_iptr,X0
ADD #1,X0
ANDC #$F,X0
MOVE X0,X:sci0_iptr ; sci0_iptr=(sci0_iptr+1) & $F

MOVE X:sci0_optr,Y0 ; iptr=optr?
CMP X0,Y0
JNE OK
MOVE X:sci0_optr,X0 ; Yes - loose oldest character
ADD #1,X0
ANDC #$F,X0
MOVE X0,X:sci0_optr ; sci0_optr=(sci0_optr+1) & $F
OK:
MOVE X:(SP)-,N
MOVE X:(SP)-,R2
MOVE X:(SP)-,Y0
MOVE X:(SP)-,X0
#endasm
end
Which puts the data coming in into a 16 byte rotating FIFO and clears TD0 which counts up in ms the times since the last character to enable the reply to be sent at the correct moment in time.

I've found that using defines within the inline assembler code is not possible - is this going to be addressed? - which makes it a little more difficult to follow.

Thoughts...

PJE

EDIT: Also, do I need to disable interrupts at the top and re-enable them at the bottom?

[petegray]

Hi PJE,

Yes, you need to save and restore the used registers (like you've done in your code).

I've not explored using multi-priority interrupts, but in the simple case, I believe you just re-enable interrupts prior to the RTI instruction.

You raise an interesting point, re: using the higher level language #defines from within assembler... I'd never considered this, because I have a habit of keeping my interrupt routines *really* small (they usually only perform a function such as setting a flag). I need to give this some more thought.

Thanks,
-Pete.

[petegray]

I gave it some thought - the new version now promotes the #defines so that they're accessible from assembler.

I have a question...

StatiC uses the '^' and '@' characters as pointers and address-of operators. I did this in an attempt remove the operator ambiguity present in C.

The ambiguity is gone, but I wonder if I've simply added to the confusion by introducing more strange characters to the language. The point being (and I'll eventually get around to asking the question!) - I could add a compiler switch that will allow the user to specify which symbol set they'd like to use ('original StatiC' or 'C'), or I could simply change the compiler to use the C '*' and '&' symbols.

So, do I...

1. Leave it as it is.
2. Add a compile-time switch so the user can choose
3. Simply adopt the C standard

All of which would be fairly easy to implement. The only drawback being - because of operator ambiguity and StatiC's lack of a statement terminator - that option #2 and #3 would require minor adjustments to the language syntax.

-Pete.

[PJE]

Hi Pete,

I feel that StatiC is so different from C that I'd stick with the '^' and '@''.

Any progress on the array access via a constant (array[1]=x) ?

Regards,

Peter, Oops PJE ;)

[petegray]

Hi Peter,

Yeah, I think I'll make the compiler default to the original, and provide an override switch to allow C-style.

Mucho progress on the optimization. All of the cases...

array[k] = var
var = array[k]
array[var1] = var2
var2 = array[var1]
var = array[expression]
etc

...have been optimized to use the x:(r2+n) form. Those push/pops have all gone. I finished translating the last of the pcodes for the DSP target this morning... let the testing of StatiC v1.0 begin !

-Pete.
p.s. Still looking forward to receiving your code, so I can run it through the new compiler / optimizer.

[petegray]

Ooops. That'll teach me to check the "Disable Smilies" box.

Should have been...

x:(r2+n)

[PJE]

Hi Pete,

Good to here about the optimization. I've just emailed you the source and output files for my serial protocol converter.

Regards

Peter

[PJE]

Hi Pete,

Originally posted by petegray
Yeah, I think I'll make the compiler default to the original, and provide an override switch to allow C-style.

While you're at it why not make it ignore ; as well?

It would be nice to have multiple statements on a line

var1=1 ; var2=2 ; var3=3 (;)

Although

var1=1 var2=2 var3=3

Seems to work as well, but is not very readable and more prone to errors

Thoughts

Peter

[petegray]

Hi Peter,

re: ';' - already in the new version.

Those quirky shift-left/right statements have been replaced with the C-style '<<' and '>>' operators, too.

Also, to remove the operator ambiguity for folks using the C-style pointers, the 'if' and 'while' have been modified to include '(' and ')'. e.g.

while (condition) ...

and

if (condition) ...

I've also added the 'for' loop (again, C-style) to the language, as well as the #inline directive (#asm is still supported, too).

Once I flush-out any issues with all the new code, I'll re-think the FSM aspects, and see if I can make any improvements there, too.

Regards,
-Pete.