Forcing 16 Bit Constants

pjv · 2009-02-19 21:23

@ Terry;

Terry I am using SX/B, and in calling some routines, I require 4 Paramerters, one pair of which is from a selection of 16 bit pre-labeled constants.

When I assign (EQU) a 16 bit constant·to a label, and the leading (MSB) portion of that constant happens to be 00, then the compiler appears to treat it as an 8 bit constant, and throws an "invalid number of parameters" error. I know there are work-arounds possible, but can this be circumvented in the compiler?

ReadFram __Param1, __Param2, 0, 0                                     ' direct assignment works fine
 
Address1 con $1234
ReadFram Address1, 0, 0                                               ' also works fine
 
Address2 con $0034                                                    'intended as a 16 bit constant
ReadFram Address2, 0, 0                                               'throws a hairy

Cheers,

Peter (pjv)

JonnyMac · 2009-02-19 21:35

Peter,

Until the compiler is modified could you declare your routine as using 3 or 4 byte parameters and then do this?:

SUB READ_FRAM
  ASM
    JB    __PARAMCNT.2, @RF_Start
    MOV   __PARAM4, __PARAM3
    MOV   __PARAM3, __PARAM2
    CLR   __PARAM2
 
RF_Start
    ; code here

  ENDASM
  ENDSUB

-- I'm asking/suggesting for my own edification.

pjv · 2009-02-19 21:50

Hi Terry;

As I said, there are work-arounds, but that is so inelegant, and somtimes I already use up the __ParamCnt spot, so that is not available.

I'm hoping something simpler is possible.

Also, sometimes the constants are calculated at compile time, and one is not aware that the MSB portion is zeros.

Cheers,

Peter (pjv)

Peter Verkaik · 2009-02-19 22:09

Bean,
If I recall correctly, there was such a request in the beta forum,
and the suggestion was made to allow
subname [noparse][[/noparse]type] var/constant, ....
where type is optional and could be word/byte
so sxb could convert the variable/constant to the specified type.

regards peter

Zoot · 2009-02-19 22:10

Bean -- I've actually had this same scenario. My preference would be that if the constant is defined as a Word (i.e. with leading zeros or with the high byte filled with a non-Z value) then the constant should get compiled as Word, and perhaps with LSB and MSB portions defined as well. I think this makes sense, since any variable based ops (such as passing params to a sub/func) always treat a Word variable as two bytes for paramcnt purposes. This would make the handling fairly consistent (a Word is a Word is a Word -- ha ha).

So this would compile to a single byte:

SomeCon CON $FF

But this would be a word:

SomeCon CON $0FF

as would this

SomeCon CON $FFFF

p.s. My workaround has been this:

SomeCon CON $00FF
SomeCon_LSB CON SomeCon & 255
SomeCon_MSB CON SomeCon >> 8

'......
result = SomeFunc SomeCon_LSB, SomeCon_MSB

Which isn't awful, but isn't great either.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Bean · 2009-02-19 23:54

Yes, I want to implement it like this:

SomeSub SUB 3,4,Byte,Word,Byte

This will compile to always make the 2nd parameter a WORD by setting __PARAM3 to zero if needed. And the last byte is optional and will be __PARAM4.

I just never got to it.

I will look into doing this change, but I don't want to keep changing stuff while Jon is working on the documentation. Maybe after 2.01 is released ?

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

Post Edited (Bean (Hitt Consulting)) : 2/20/2009 12:46:52 AM GMT

Zoot · 2009-02-20 00:26

I recall that discussion from the beta forum, but I think that's a separate (and sometimes related) issue. I think the declaring of word constants (either w/leading zeros, or possibly a suffix to force it) would be great and doesn't necessarily need to affect a new paradigm for function/sub calls. For example, I may have routines that require a Word to be IREADed or RETWed, and if the Word (perhaps a calibration number) is <= 255 I won't get the upper byte defined (in SX/B). Or what if you are building a data table of Words -- if some of the data is predefined constants, then again, this won't work without an LSB MSB workaround, because there won't be a highbyte.

I don't think this needs be directly related to optimization for multi-byte/multi-word sub/func calls. If I remember that discussion related as much to optimizing code and obviating the need for paramcnt in mixed var cases without the user having the manually clear the upper byte before the call.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Peter Verkaik · 2009-02-20 01:05

@Pjv,
If you·don't need the full 16bits·range for·your constants,
you could declare them with b15 set.
addr1 con $9234
addr2 con $8034
and simply clear __param2.7 upon function entry.
You don't need to use __paramcnt then,
nor do you explicitly need to clear __param2
if the actual value <= 255.

regards peter

Post Edited (Peter Verkaik) : 2/20/2009 7:49:19 AM GMT

pjv · 2009-02-20 03:53

Hey All;

Thanks for your thoughts and inputs.

What I was hoping for was something along the lines of what Zoot is saying.... a simple ability to force the compiler to treat a constant as a 16 bit number, including calculated constatnts, regardless of the value of the MSB.

And PeterV; that is actually a clever and not too costly way of a work-around.

Cheers,

Peter (pjv)

Bean · 2009-02-21 14:16

I have posted version 2.00.13 which has both WCON for declaring word constants and allows you to specify the SUB and FUNC parameters as BYTE or WORD.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

Bean · 2009-02-21 14:41

Dang it, I already found a problem with 2.00.13. If you specify a WORD parameter the compiler will promote a byte to a word.
But if you specify a BYTE parameter and use a WORD is doesn't error (as it should).
I will fix that ASAP.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

JonnyMac · 2009-02-21 15:54

If you specify a Byte but pass a Word shouldn't it just use the LSB?

Zoot · 2009-02-21 16:19

I think Bean's point in throwing an error in this case is that *if* you have *required* the sub/func to be passed a word, it should get a word. Otherwise, you could leave out the word,byte,byte type spec and let the chips fall where they may. The original impetus for this during beta discussions was to (at times) obviate the need for loading and subsequently parsing paramcnt.

My own work tries to not rely on paramcnt for funcs/subs too much as the code overhead can really add up (if you are loading up, say, three params plus paramcnt, right there that's 8 instructions before the CALL itself).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Bean · 2009-02-21 16:33

Jon,
I guess I could just use the LSB... That would probably be better.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

Post Edited (Bean (Hitt Consulting)) : 2/21/2009 7:05:34 PM GMT

Peter Verkaik · 2009-02-21 16:56

I agree with Jon that if there is truncation, a word
should truncate to·the LSB part.

regards peter

Peter Verkaik · 2009-02-21 18:30

A note on using type specifiers:

Many of my library subs/funcs require word parameters
and so it would make sense that I add WORD,WORD to
the declaration.
Many of these subs/funcs are also called from within
the library by using
· subname __param1,__param2,__param3,__param4
which simply compile into
· call @__subname

Now, when adding the WORD,WORD to the declaration
the calling should change to
· subname __wparam12,__wparam34
However, this compiles into
· MOV __PARAM1,__WPARAM12_LSB
· MOV __PARAM2,__WPARAM12_MSB
· MOV __PARAM3,__WPARAM34_LSB
· MOV __PARAM4,__WPARAM34_MSB
· call @__subname

so there are 4 redundant instructions added.

Can sxb check for __wparamx and leave out the redundant
MOVs if the __wparamx is in the correct place?

regards peter

pjv · 2009-02-21 21:02

Thanks for the mod Terry; that works wonderfully!

Cheers,

Peter (pjv)

Forcing 16 Bit Constants

Comments