Bug, feature or am I missing something

Javalin

evening all,

Not to jump on the current trend of IDE bashing, but either this is a wierd one, or more likely I am missing something.

I am starting·a cog with an Assembler routine.· Currently all it does is keep updatin a variable in hub (shared) ram.· My Cog start code is:

  ...
  byte asmSamplerData[noparse][[/noparse]100] 
  long s, ms, us
  
  byte  myCogID
  byte  SPI_CLK, SPI_CS, SPI_DO, SPI_DI
  byte  index
  word  adcMUX
  long  adcData[noparse][[/noparse]13]
  long  stack0[noparse][[/noparse]30]
  long  running
  long  currentSample
  long  tempSample
 
  ...
 
  pub Start
 
     asmSamplerData := 75
     myCogID := cognew(@samplerEntry,@asmSamplerData)

The (significant part of the) cog code is:

DAT                     
                        org
samplerEntry            mov     t1_ptr,par                                      ' SPIASM Block
                        mov     adcChValue,#100
                        wrbyte  adcChValue,t1_ptr

Simple?

No.· That doesn't work.· The "asmSamplerData" value stays at 75 - as initialized in the SPIN.

If I change the order of the variable declarations to put

  byte asmSamplerData[noparse][[/noparse]100]

at the bottom of the list.· It works and the "asmSamplerData" goes to 100.

Bizarly I have another bit of code in the same app that works with the byte varname[noparse][[/noparse]100] at the top and it works fine.· This issue also works if you change it to "long asmSamplerData[noparse][[/noparse]100]"

using IDE 1.05.5

Appologies if this has been seen and is a "gotcha" already - did look quickly.

If nothing else (aka not a bug) a "gotcha" or a compiler warning would be·useful.

Thanks all,

James




Post Edited (Javalin) : 10/4/2007 7:01:07 PM GMT

Rayman

I think that the parameter address passed by cognew has to be long aligned...
Try writing:

aligned long

In the line just before "byte asmSamplerData[noparse][[/noparse]100] "

Javalin

Playing with it more the:

word  adcMUX

Seems to be the culprit.

James

Phil Pilgrim (PhiPi)

The address passed via par must be a long address, since the two lsbs of par are always zero. Since asmSamplerData is a byte array, its alignment could be anywhere, depending on where in appears in the declaration list. 'Better to declare it as a long array, so it will be properly aligned.

-Phil

Javalin

thanks Phil - thought I would be missing something.

I guess the other code is in memory later, as its a bigger lump of memory - hence why it works

Been going arround this one for about 2 hours!

James

deSilva

As Rayman already supposed, the value for the second parameter of a COGNEW is crippled to 14bits; only bits 2 to 15 are transmitted to the COG, the other bits are filled with zeroes.

There are good internal reasons for this (see Propeler Manual, and many discussions here, deSilva Tutorial, etc., etc.)

The sequence of VAR allocation is changed by the compiler:

LONG first, then WORDs , last BYTEs

So having an odd number of words declared will bring you into trouble.
Putting your byte array to the end had an effect, as now exactly 6 byte variables were allocated before the array, just compensating for the odd numbr of words.

Be careful! SPIN is no fun

Ken Peterson

Oh, but it IS fun!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Phil Pilgrim (PhiPi)

I do agree: a warning whenever a poorly-aligned address is provided to cognew would be a nice touch, since it's hard to imagine a legitimate reason for doing so. However, I don't believe the @variable values are known at compile time (although it seems the alignment, at least, could be), so the condition may be difficult to detect in time.

-Phil

deSilva

The address of a VAR variable of a general object can never be known at compile time -
See my instructive posting about "The four different kinds of @"

As the tricky re-sorting of variables makes it unnecessary for the compiler to know anything about their alignment, I doubt that this information is easy to obtain..

Edit: I have to correct myself. The last phase of the compiler MUST know the relative adress of any variable, this could be checked for long alignment - however this last phase will most likely have no idea of the context in which this adress is used...

Post Edited (deSilva) : 10/4/2007 8:12:58 PM GMT

Phil Pilgrim (PhiPi)

deSilva,

I disagree. Since it's possible, by a simple visual inspection of each object, and without reference to any other loaded objects, to determine a VAR variable's alignment (an operation you so rightly performed above, BTW), there's no reason that alignment data can't be known at compile time, even though the actual addresses are not. It's inconceivable that all the instances of every object's variables get thrown into one huge blend-o-matic, allowing one instance's bytes to become separated from its longs by another instance's words, for example.

-Phil

deSilva

Phil, your argument is hardly to beat What I was insinuating was, that the compiler AT THE MOMENT avoids to need to know anything about it.... So it would take work to additionally include this just for this single application...

On the other hand: The second parameter of COGNEW ist just ... a value. So it can be (and is) computed in a general way.

As the compiler is doing no "constant optimisation", @var will be postponed to execution time as well as any more complex construction. Ex:

COGNEW(@asm+4, $8000-100+i*4)

Phil Pilgrim (PhiPi)

Good point, deSilva. The use of an expression in that slot muddies the waters quite a bit and, in general, makes it impossible to determine alignment at compile time. Imagine if that expression were to contain a function call! So a pseudo-constant like @variable is a special (albeit common) case that's not likely to be addressed anytime soon for error/warning processing. Oh, well...

-Phil

Javalin

Hi Phil,

So I guess a valid work arround would be to have the:
cognew(@entry,@alongvariable)

and in the "alongvariable" pointing to an array of bytes?

Seems a shame to have to use a 512 array of longs to hold 512 bytes.

Spose otherwise you'd have 128 longs and break it up that way?

Cheers,

James

cgracey

If you wanted 512 bytes to be pointed to by PAR after cog boot, you could·declare (and point to) 128 longs, and then treat them as 512 bytes. It's just critical that PAR point to a long. What you do after that is your business.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Javalin

thanks Chip.

deSilva

What Chip suggests does not lead to very readable code. There is no safe way to align a byte array to longs....

For all those complications I do not recommend using PAR , but using any simple DAT variable... Examples can be found in deSilva's Tutorial and in some discusions here and there...

E.g.:

byteArrayPointer := @asmSamplerData
COGNEW(@asm,0)


.....

asm
...
byteArrayPointer LONG 0

Rayman

deSilva said...
There is no safe way to align a byte array to longs....

· Why not just:
·
long·byte asmSamplerData[noparse][[/noparse]100]

The manual suggests this should work.· I'm pretty sure I've used something similar myself...


·

deSilva

Oops... It was SIMILAR without doubt


But what you can of course do is put IT ALL into the DAT section:

DAT
:dummy LONG 0 ' allign
asmSamplerData BYTE 0[noparse][[/noparse] 100 ]

Post Edited (deSilva) : 10/5/2007 6:07:57 PM GMT

Rayman

I thought we were just talking about the DAT section... I've heard everything in the VAR section is automatically long aligned.

deSilva

Neither - nor.
When you look at the syntax it's all in VAR.
I gave the rules for re-ordering again in the sixth posting above.

Phil Pilgrim (PhiPi)

Something that might be useful for VARs is an align modifier:

[b]VAR[/b]
  [b]byte[/b] buffer[noparse][[/noparse]64] [b]align long[/b]

Another option would be a way to alias one variable to another:

[b]VAR[/b]
  [b]long[/b] lbuf[noparse][[/noparse]16]
  [b]byte[/b] buffer [b]alias[/b] lbuf

Granted, the notation BYTE[noparse][[/noparse]@lbuf][noparse][[/noparse]index] covers the latter situation adequately, but any enhancements for improving code readability are always welcome.

-Phil

deSilva

I like "align long" a lot! This should also address the need for "align 64"

Rayman

I think I decided that it is easier just to pass the address of a location in the DAT section to Cognew.

deSilva

Good choice!