INTERRUPT(X) works oddly

Questions about the BASICtools and MakeItC
Post Reply
AMDlloydsp
Posts: 99
Joined: Mon Apr 15, 2013 3:51 pm
Location: NE Central FL

INTERRUPT(X) works oddly

Post by AMDlloydsp »

Bruce,
this code:

'------------------------------------------
main:
INTERRUPT(1)
print "this didn't work"
'------------------------------------------


When run on the SuperPro, it causes the SuperPro itself to crash. (not the BasicTools, which are still in control, and can still stop the program)

The "executing" message in the tools screen never finishes. The print never occurs.
Suspecting it might be BASICtools, I added some IO instructions to scope. Anything else added to the program fails to happen, as well (which is why I suspect the SuperPro is crashing, not the tools).

Changing the expression in the INTERRUPT(X) to zero, fails in the same manner.

I'm at a loss, here. Since the default is INTERRUPT(NZ), I would assume setting it to '1' would not affect anything.
I understand that setting it to zero will clobber any realtime stuff.

In replacement of the literal "1", I've also tried non-zero 'single' and 'integer' expressions. Same results.

This was most recently tested on a bare, brand-new (received today) SuperPro with the development kit; no other software ever loaded, and no devices except the USB serial dongle attached.


Thanks,
Lloyd



basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: INTERRUPT(X) works oddly

Post by basicchip »

Obviously something we never tried, but we never thought to. Interrupts are ON by default at least the ones we are using for the UARTs. The code in the runtime is

Code: Select all

unsigned save_cpsr;

void f_intsw() {
	if (reg_accum) 	restoreIRQ(save_cpsr);
	else 			save_cpsr = disableIRQ();
}
So if the first thing you do is turn them on(what is passed in the reg_accum) you get whatever is in save_cpsr. Now in most cases this will be 0 as that is what C sets global variables to. And if you turn them off after that and back on, you have disabled the UART interrupts, so nothing will ever come out the transmit buffer, and the chip will appear to be dead, though it is just sitting there waiting for ever, for an interrupt that will never occur.

Just to make sure I ran the expected case and that works as advertised.

Code: Select all

interrupt(0)
interrupt(1)
print 1234
As to Interrupt(NZ), well BASIC automatically declares variables and all variables are initially set to 0. So you have declared a variable NZ which is 0, and that turns off interrupts. Same as Interrupt(X).

Anyway, you see Ex instead of Executing is because you disabled UART interrupts so only the first 2 characters are sent out when the UART transmit interrupts are turned off.

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: INTERRUPT(X) works oddly

Post by basicchip »

PS, I'll add a note in the help page for INTERRUPT

AMDlloydsp
Posts: 99
Joined: Mon Apr 15, 2013 3:51 pm
Location: NE Central FL

Re: INTERRUPT(X) works oddly

Post by AMDlloydsp »

As to Interrupt(NZ), well BASIC automatically declares variables and all variables are initially set to 0. So you have declared a variable NZ which is 0, and that turns off interrupts. Same as Interrupt(X).
-----------
Awww... c'mon, Bruce. I used "NZ" to indicate 'non-zero argument' and "X" to indicate 'any argument'-- That's pretty conventional language, even to us novices who've only been doing it professionally for 44 years. ;)

But this: "Just to make sure I ran the expected case and that works as advertised."? I have to ask... WHO's expected case. The ordinary grunt programmer assumes, fairly, that "on is on, and off is off".

But that aside, I did use NON-ZERO variable arguments; literals, initialized single-precision variables, and initialized integer types, all. And, as you duplicated, it does not turn on the interrupts, it turns them off. I'm still not clear on why the initial call to INTERRUPT(with_a_non_zero_argument) would ever resort to some defaults in the registers when an actual argument has been passed? (does that make sense?) Yes, I understand the C code, I just don't understand why it's restoring stuff from a saved state, instead of asserting a state based on the argument.

Yes... the note in the docs would be helpfull to future walkers of this path.

Please don't get me wrong. I love this little board, and the development language. Despite the language's few 'quirks', it's a fast, facile, and very capable way of putting together sophisticated, fast-running code in a hurry.

I did a dual-axis polar positioner system just LOADED with complex two-axis polar-coordinate trig - including debugging - in two days; It works a treat, and on real, physical stepper motor-driven hardware, not just in software.

I'm just a 'niggler' for fully understanding the platform I'm working with, so...despite what sounds like complaints... "Hats off to you." I make a note in my own manual of everything you tell me. :idea:

Lloyd

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: INTERRUPT(X) works oddly

Post by basicchip »

NZ, X might mean non-zero in ASM or X as unknown in RTLs.

This is a version of BASIC, so show me any BASIC that treats it that way. We are not here to invent a new language, but to leverage off work that has been done before. I am am always VERY critical of people that start a new language from a clean slate. Are we completely true to that paradigm, no but we take trying to fit into what has been done before seriously. Some notable exceptions, rather than PEEK and POKE we just use C pointer constructs to access peripheral registers or memory. If you like PEEK and POKE, either #define could be used or your own SUB/FUNCTION.

Code: Select all

#define PEEK(x)    *(x)

SUB POKE(addr,val)
  *addr = val
ENDSUB
Yes #define is C specific and comes from the C pre-processor, but again we grabbed an existing well documented piece of code and applied it to our tools. We don't have the time, inclination or desire to design our own pre-processor.

Other examples where we break the mold are PRINTF and SPRINTF, which you can actually write in BASIC and we support limited PARAMARRAYs to do that. The reasoning here was, we used that code in the runtime environment, so when we got to adding the floating point we added the ability user BASIC program to call that code that existed in the firmware anyway.

I've been programming originally in BASIC on a GE time share system going back to around 1968. Later Fortran, APL, LISP, Algol, Pascal, PL1, C, Tcl, Verilog, VHDL ...

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: INTERRUPT(X) works oddly

Post by basicchip »

PS, our frame of reference was that interrupts would normally be on, just because UARTs would not work without that.

So the typical use case of INTERRUPT(0), was to turn them off for bit-banging code on the CPU. And then restore them later.

I'm not saying what you did was wrong, and yes we will fix that in a future firmware, though it may never make it into the field on existing products. But it is something we never thought to try, and the code was written that way because it was (ie. no good reason).

AMDlloydsp
Posts: 99
Joined: Mon Apr 15, 2013 3:51 pm
Location: NE Central FL

Re: INTERRUPT(X) works oddly

Post by AMDlloydsp »

Yeah, I can understand that frame of reference. I approached it from a "I don't know what state the machine is in" point of view, being a strong believer in doing all my own explicit initializations of states I can control.

I started the same year as you did (though, non-professionally, as a student-assistant) first on WANG programmable calculators (hand-punched cards -- not key-punch, but using a STYLUS on a rubber mat!), then on an IBM 1140, then IBM's TSO (time-sharing operations), using BASIC, Batch PL-1 and real-time interpreted PL-1, COBOL, WAT-4, WAT-5, and Fortran IV. I wrote business simulation packages for the University of Central Florida (then Florida Technological University). I built robots and video games as a hobby from 1972 on. I had the first "personal computer" of anyone I knew, or anyone known by anyone who knew me... and it was NOT a TRS-80 or a MITs/Altair, or any other kit. I designed the ALU from scratch, and built it from Sylvania SUHL logic on Augat wire-wrap panels.

Later I worked in C and C++ (starting on Borland C, and moving to MS as required), many flavors of UNIX (AIX, SCO, HPUX, LINUX, etc, etc), and about twelve different processor's assembly language (as I was a hardware designer in the 80's and early 90's). I personally designed all the hardware for the Commodore Computers Hard Drive system called the Lt. Kernal, and wrote about half of its DOS.

Now I build manufacturing automation, so I'm always looking for faster, better, more capable tools.

As I said, I have no complaints about your product. It's a 'keeper'. I just want to fully understand what I am about to bolt into one of my machines.

I guess we could go "experience for experience" with one-another... that just wasn't where I wanted to go in our discussions, and I don't think it's productive to our goals.

Bruce, you don't have to defend any deficiencies in the code -- real ones, or ones imagined just by me. If I'm wrong and they don't exist, just say so. If they're actual bugs, just say so. If they're operating limitations, just say so. If you just didn't feel like writing the code.... just say so!

I don't care about 'fault and cause', just resolutions, even if I have to work around problems (I have a penchant for discovering the need for such work-arounds). I just want to design and build machines, and would rather not do it with Z80s, if you don't mind! (but I still could! :lol:)

We have almost identical backgrounds and experience.

Friends?

Lloyd

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: INTERRUPT(X) works oddly

Post by basicchip »

Don't take my response as unfriendly, yes I could use better social skills. Forgive me I'm an engineer, and talk to computers often more than people.

Yes, it is a bug. An important one, no. And I can theorize about how it got that way, and the reasoning is half right.

Just FYI I was the second engineer at Corvus Systems, so I go back to those disk drive back days, and other than the 68HC11, the Z80 was among my favorite processors to write assembly code on. I'm quite happy with the ARM, and other than the compiler itself, I'm quite happy to be not writing in ASM

AMDlloydsp
Posts: 99
Joined: Mon Apr 15, 2013 3:51 pm
Location: NE Central FL

Re: INTERRUPT(X) works oddly

Post by AMDlloydsp »

the Z80 was among my favorite processors to write assembly code on. I'm quite happy with the ARM, and other than the compiler itself, I'm quite happy to be not writing in ASM
---------
Me too! I built most of my serial protocol converters around Z80A chips running at analog TV color burst frequency (3.579545MHz).

But things move on. Back then, 1MIPs was screaming-fast for a micro; It's not even fast enough to be considered 'slow', anymore.

ANYway... thanks for the fill-in on the INTERRUPT() statement. I will make the appropriate adjustments.

LLoyd

Post Reply