[resolved][puzzle] substitute

kuroneko · 2010-12-27 00:05

Not much of a challenge I admit. But it's SPIN-only so maybe not too scary. Anyway, longfill is on holiday and longmove has to fill in. What would a replacement function look like? Just complete the template function and if it's not too much trouble attach it as SPIN source rather than a [noparse]

[/noparse] block.

PRI longfill_using_longmove(StartAddress, Value, Count)

  if Count
    ' longfill replacement code

See postings #14 and #15 for possible solutions (which I had in in mind that is).

Phil Pilgrim (PhiPi) · 2010-12-27 00:39

kuroneko,

I believe that Spin is smarter than that. IIRC, it always selects a move order to avoid stepping on its own toes -- assuming that's what you had in mind.

-Phil

kuroneko · 2010-12-27 00:44

When did impossible ever stop us? There is a solution (or I wouldn't have posted the challenge).

Phil Pilgrim (PhiPi) · 2010-12-27 00:55

Who said impossible? It's just that the obvious solution can't be the right one. And since you're the one posing it, I assume it has something to do with a quirk in the byte code interpreter -- perhaps doing the "wrong" thing with negative addresses or positive addresses beyond $ffff.

-Phil

Heater. · 2010-12-27 01:05

kuroneko,

Having been playing with Fast Fourier Transform recently the answer is obvious, divide and conquer and do it recursively. Full solution in a test harness attached.

PRI longfill_using_longmove(StartAddress, Value, Count)
    if Count
        'longfill replacement code
        longmove(StartAddress, @Value,   1)                       'Fill in the first element
        longfill_using_longmove (StartAddress + 4, Value, Count - 1)  'Then fill in the rest

Edit: Oops...Had a bug in my first line,

kuroneko · 2010-12-27 01:10

@Heater: I sure hope you mean longmove(StartAddress, @Value, 1)! While it doesn't do any harm it's obviously wasted time

OK, just checked your code and there it reads "1".

Heater. · 2010-12-27 01:12

Yep, fixed as you post.

"Wasted time" Who said anything about efficiency?

kuroneko · 2010-12-27 01:40

Heater. wrote: »

"Wasted time" Who said anything about efficiency?

Fair enough, given that this is only a theoretical exercise

FWIW, trigger for this challenge was a (now void) requirement to copy a block of memory from DAT to VAR without having overlap protection kick in (i.e. I wanted the first long transferred first).

Heater. · 2010-12-27 02:19

In the interests of algorithmic symmetry, obfuscation and inefficiency and end of year fun I prefer a solution with more elegance like this:)

PRI longfill_using_longmove(StartAddress, Value, Count)
    'longfill replacement code
    if Count == 1
        longmove(StartAddress, @Value, 1)                                           'Fill in the only element
    elseif Count > 1
        longfill_using_longmove(StartAddress, Value, ((Count+1) / 2))                    'Fill in the first half
        longfill_using_longmove(StartAddress + (Count / 2) * 4, Value, ((Count+1) / 2))  'Fill in the second half

Edit: Fixed Baggers zero length Bug.

Baggers · 2010-12-27 02:57

Heater, you forgot it Count==0 ?

Ariba · 2010-12-27 03:14

OK here is my solution

Not more serious than heaters code, but much more efficient...
and with testcode that shows that it works!

_clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

OBJ  term: "Parallax Serial Terminal"

PRI longfill_using_longmove(StartAddress, Value, Count)
  if Count
    longmove(StartAddress, Value, Count)


PUB testcode | p
  
  'start terminal and wait 5 seconds
  term.start(115200)            
  waitcnt(clkfreq*5-(byte[$69]-=4) + cnt)
  
  'use the new methode
  longfill_using_longmove($7000, $11223344, 16)

  'show written memory on terminal 
  repeat p from $7000 to $703F step 4
    term.hex(long[p], 8)
    term.char(13)

Andy

kuroneko · 2010-12-27 03:28

@Andy: Byte code patching doesn't count, sorry!

But 10 points for hiding it cleverly.

Heater. · 2010-12-27 03:36

Baggers, OK fixed that.

Honestly, who would be so daft as to want to fill a zero length buffer....

Ariba · 2010-12-27 04:49

Attached is my serious solution. Hope I get another 10 points...

Andy

kuroneko · 2010-12-27 05:39

Ariba wrote: »

Attached is my serious solution. Hope I get another 10 points...

+10 (that's similar to what I used)

PRI longfill_using_longmove(StartAddress, Value, Count)

  if Count
    long[StartAddress] := Value
    longmove(StartAddress + 4, [COLOR="red"]NEGX|[/COLOR]StartAddress, Count - 1)

[resolved][puzzle] substitute

Comments