Matters of style question

jcwren

Being a long-time assembly programmer, but new to PASM, there's a couple things I'm curious about.

First, is there an idiom for clearing and setting carry? Right now I'm using "add par, #0" to clear carry (where carry indicates to the caller the routine succeeded).

In PASM, is clkfreq accessible somehow at compile time? I have a couple constants I want to define that are based on the clock rate, but I'd prefer to do this at compile time rather than runtime.

--jc

kwinn

As far as I can see there is no specific set or clear instruction for the flags but there are many instructions that can set or clear the flag. Usually I specify wc in one of the instructions that is already part of the subroutine to set/clear the carry before exiting. Saves an instruction.

CLKFREQ or clkfreq is accessible from PASM or Spin - see page 63 of the propeller manual for an explanation.

jcwren

Unfortunately, DJNZ, often the last instruction, leaves the carry set, so I need to clear it to indicate success. Hence the "add par, #0 wc" to clear carry. I thought there might be something a little classier I hadn't seen yet.

clkfreq is readable, but I'm looking for a compile time option. In the SPIN code, delay1200 microseconds would be "delay1200us := clkfreq * 0.00120". In assembly, that would force doing division, something I'd hoped to avoid. I was looking for something like "delay1200us LONG (CLKFREQ / 1_000_000) * 120". While page 63 does state "Objects that are time-sensitive should check CLKFREQ at strategic points in order to adjust to new settings automatically", I'm not worried about this (and I wonder how often people actually change the clock speed on the fly anyway).

I guess I'll have to do that in SPIN code, and pass it in the PASM, rather than a constant.

--jc

Mike Green

DJNZ does not leave the carry set unless you have WC indicated.

At compile time, you can use _CLKFREQ in a constant expression.

If a program is loaded off an SD card, most loaders will set the clock to what's specified in the source code. Some OS like Sphinx normally don't do that and keep the same setting that was specified for the OS. Since several different crystal / clock speed / clock mode combinations are in use, it would be more helpful for a program not to assume what the clock frequency is (at compile time).

jcwren

That's true about DJNZ, but the real issue is forcing carry to a known state, rather than assuming it's set one way or the other several instructions back. That way leads to madness.

somevar long _CLKFREQ

results in an 'Undefined symbol' error for me.

Mike Green

Hmm. There's nothing I could find in the Propeller documentation that would prohibit the use of _CLKFREQ, _CLKMODE, or _XINFREQ in constant expressions if they've been defined.

As far as setting and clearing the carry and zero flags, whatever works in one instruction is fancy enough.

Phil Pilgrim (PhiPi)

I think the problem might be that _CLKFREQ has to be defined explicitly, rather than expecting the compiler to derive it at compile time from _XINFREQ and _CLKMODE. It's not clear to me why it couldn't, though.

-Phil

BradC

jcwren said...
In the SPIN code, delay1200 microseconds would be "delay1200us := clkfreq * 0.00120".

Have you actually tried that piece of code?

In spin what you will get is :

2                        X := CLKFREQ * 0.00120
Addr : 0018:             35  : Constant 1 $00000000
Addr : 0019:             C0  : Memory Op Long POP Address READ 
Addr : 001A: 3B 3A 9D 49 51  : Constant 4 Bytes - 3A 9D 49 51 
Addr : 001F:             F4  : Math Op *     
Addr : 0020:             65  : Variable Operation Local Offset - 1 Write

You are multiplying the CLKFREQ with $3A9D4951 which is the floating point representation of 0.0012

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

jcwren

Brad, hadn't tried it yet, still have to build a little hardware up. But I did wonder about that. I suppose the alternative is X := (CLKFREQ / 1_000_000) * 120

--jc

BradC

jcwren said...
Brad, hadn't tried it yet, still have to build a little hardware up. But I did wonder about that. I suppose the alternative is X := (CLKFREQ / 1_000_000) * 120

--jc

Yep. That will do the job. It's how I do it also.

I was looking for a CLKFREQ define I could use in PASM also, but I've just resulted to have SPIN do the calculation at runtime and set the right value in the DAT section before I launch the cog.

It would not be incredibly difficult for the compiler to calculate the clock frequency based on the defines set at compile time, but none of them currently do it. bst does not calculate the clock frequency until the object linking stage, and by then it's too late to use it as a global symbol. (The reason for that is you might have 10 objects with the clock and crystal defines in them, but we only want the one in the top object to be authoritative).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

BR

JC:

To your original question about setting flags (carry)...Phil put together a nice summary of ways to set/clear flags a while back. The attached is a slightly-organized rabble of PASM subroutine snippets I've collected over time...the snippets relevant to your carry question start at about line 168.

jcwren

Thanks! That's a handy list.

--jc