Problems with latest FPGA release

ozpropdev · 2014-03-25 03:53

Sorry Chip,

I'm still having issues with LOCBASE in the new release (24 March 2014)
Expected return result should be $E20 and returns $20.

TYPE: 57   VALUE: 04000E20   NAME: TEST_DATA

bug1			locbase	test_index,@@test_data

LOCBASE converts a 16-bit hub instruction address into a normal 18-bit hub address for use
with RDxxxx/WRxxxx instructions:

        LOCBASE D,@relative9        'get 18-bit hub address from 9-bit relative address into D
        LOCBASE D,@@relative16      'get 18-bit hub address from 16-bit relative address into D
        LOCBASE D,S                 'get 18-bit hub address from S[15:0] into D

Cheers
Brian

cgracey · 2014-03-25 04:07

ozpropdev wrote: »

Sorry Chip,

I'm still having issues with LOCBASE in the new release (24 March 2014)
Expected return result should be $E20 and returns $20.

TYPE: 57   VALUE: 04000E20   NAME: TEST_DATA

bug1			locbase	test_index,@@test_data

LOCBASE converts a 16-bit hub instruction address into a normal 18-bit hub address for use
with RDxxxx/WRxxxx instructions:

        LOCBASE D,@relative9        'get 18-bit hub address from 9-bit relative address into D
        LOCBASE D,@@relative16      'get 18-bit hub address from 16-bit relative address into D
        LOCBASE D,S                 'get 18-bit hub address from S[15:0] into D

Cheers
Brian

Brian, I'll look at this right away when I get into the shop this morning. Maybe I didn't solve the whole problem. I actually didn't even test it, myself, because it seemed so obvious to me what the problem had been. That was a mistake! I'm sorry. We'll have this working in the next several hours.

I also want to see if I can get COGNEW to fail like potatohead experienced.

cgracey · 2014-03-25 14:08

It looks like this is an assembler issue!

I re-ran the LOCLONG tests from yesterday and they DO PASS now, so that hardware fix was good.

What we are left with is an assembler issue handling @@ properly. I'm working on this now...

cgracey · 2014-03-25 14:50

Brian,

The assembler seems to be fine, after all.

If, in your example, 'test_data' was declared under an ORG (instead of an ORGH), it would be a cog address, and not a hub address. That would explain what's going on. You'd need to declare it under an ORGH to make it work right.

Sapieha · 2014-03-25 16:08

Hi Chip.

BUT how about if I write in ORG declare but will address HUB @@SD_Table

cgracey wrote: »

Brian,

The assembler seems to be fine, after all.

If, in your example, 'test_data' was declared under an ORG (instead of an ORGH), it would be a cog address, and not a hub address. That would explain what's going on. You'd need to declare it under an ORGH to make it work right.

cgracey · 2014-03-25 17:03

Sapieha wrote: »

Hi Chip.

BUT how about if I write in ORG declare but will address HUB @@SD_Table

The only thing that has to be under an ORGH is the data that will be accessed via RDxxxx/WRxxxx instructions, since you can't use RDxxxx/WRxxxx to access cog RAM - only hub RAM.

cgracey · 2014-03-25 17:42

At this point, after figuring out potatohead's COGNEW problem, I don't know of any unresolved bugs. There are likely some lurking, though.

ozpropdev · 2014-03-25 17:48

cgracey wrote: »

Brian,

The assembler seems to be fine, after all.

If, in your example, 'test_data' was declared under an ORG (instead of an ORGH), it would be a cog address, and not a hub address. That would explain what's going on. You'd need to declare it under an ORGH to make it work right.

Thanks Chip,
That was it. I assumed that all addresses would be "treated" as HUB addresses.

So the lesson here is for data in "COG" mode use the conventional way of reference

    mov myreg,_mydata


_mydata    long    @mydaya

and for "HUB" mode use the new

    locbase myreg,@mydata

Got it.

Cheers
Brian

Post Edit:

LOCBASE converts a 16-bit [color=red][b][I]hub instruction address[/I][/b][/color] into a normal 18-bit hub address for use
with RDxxxx/WRxxxx instructions:

Cheers
[/code]

Bill Henning · 2014-03-25 17:56

Chip,

There should be a way - a prefix of some sort - of obtaining the hub address corresponding to where the long was loaded from in the hub.

Given that '##' is already used for large constants/addresses for other instructions, how about having PNut understand that

LOCBASE myreg,##mydata means use the hub address corresponding to mydata's cog location, and perhaps even
LOCBASE myreg,@@mydata for the relative equivalent?

I can see wanting to use longs "underlying" a cog in the hub.

Sapieha · 2014-03-25 17:56

Hi Brian.

COG and HUB mode that is OK.

BUT how I address that in MIXED mode?

ozpropdev wrote: »
Thanks Chip,
That was it. I assumed that all addresses would be "treated" as HUB addresses.

So the lesson here is for data in "COG" mode use the conventional way of reference
    mov myreg,_mydata


_mydata    long    @mydaya
and for "HUB" mode use the new
    locbase myreg,@mydata
Got it.
Cheers
Brian

cgracey · 2014-03-25 18:20

Bill Henning wrote: »

Chip,

There should be a way - a prefix of some sort - of obtaining the hub address corresponding to where the long was loaded from in the hub.

Given that '##' is already used for large constants/addresses for other instructions, how about having PNut understand that

LOCBASE myreg,##mydata means use the hub address corresponding to mydata's cog location, and perhaps even
LOCBASE myreg,@@mydata for the relative equivalent?

I can see wanting to use longs "underlying" a cog in the hub.

I agree. I need to make a flag for the constant resolver in the assembler, so that when one of these LOCxxxx instructions is looking for data, it always uses the hub address, and never the cog address.

ozpropdev · 2014-03-25 19:56

Chip
Is it possible in future FPGA releases to have a release date or version id readable by Pnut to verify current loaded version.
Jumping back and forth from different releases to cross check tests can sometime get confusing.
This also applies to Pnut as well to match the loaded FPGA release. This would help greatly.

Cheers
Brian

potatohead · 2014-03-25 21:19

Seconded. I got caught on the wrong Pnut already. Had put it where the code for it was, and when porting to new image got snagged.

cgracey · 2014-03-25 21:52

ozpropdev wrote: »

Chip
Is it possible in future FPGA releases to have a release date or version id readable by Pnut to verify current loaded version.
Jumping back and forth from different releases to cross check tests can sometime get confusing.
This also applies to Pnut as well to match the loaded FPGA release. This would help greatly.
Cheers
Brian

I'll start using the ROM Monitor intro message for that, and match it with the associated PNut.

Bob Lawrence (VE1RLL) · 2014-03-26 07:31

I got caught on the wrong Pnut

I did that a few times so I re-named all of my pnut.exe files to include the version numbers.

Cluso99 · 2014-03-26 12:22

Just found the LOCPTRA #font problem (in my Nokia 5110 driver) where I didn't have the font table in a separate ORGH section. Fortunately I found it by removing the orgh after I had the code working

msrobots · 2014-03-27 15:39

I just added syntax highlighting for P2 PASM to the online editor.

Tested with ozpropdev's toobox. found him using a PUSHB opcode not in the last list of opcodes.

Is PUSHB still valid?

Enjoy!

Mike

cgracey · 2014-03-27 15:54

msrobots wrote: »

I just added syntax highlighting for P2 PASM to the online editor.

Tested with ozpropdev's toobox. found him using a PUSHB opcode not in the last list of opcodes.

Is PUSHB still valid?

Enjoy!

Mike

All those pushes and pops are still there.

Cluso99 · 2014-03-27 16:08

msrobots wrote: »

I just added syntax highlighting for P2 PASM to the online editor.

Tested with ozpropdev's toobox. found him using a PUSHB opcode not in the last list of opcodes.

Is PUSHB still valid?

Enjoy!

Mike

PUSHA is possibly WRLONG D/#,PTRA++
PUSHB is possibly WRLONG D/#,PTRB-- because B works in reverse
PUSHX is possibly WRAUX D/#,PTRX++
PUSHY is possibly WRAUX D/#,PTRY--
POPA is possibly RDLONG D,PTRA--
etc

You might like to start a new thread and give us the details of the online editor. I have only partly followed your progress on the P1 thread.

msrobots · 2014-03-27 16:13

Thanks.

Looks like I lost it while extracting the opcodes from the post.

will update the editor soon.

Enjoy!

Mike

msrobots · 2014-03-27 16:20

you might like to start a new thread and give us the details of the online editor. I have only partly followed your progress on the P1 thread

Yes. It is on the P1 thread since it uses OpenSpin converted to JavaScript by @Heater. And OpenSpin does not yet compile P2 code. But hopefully it will at some point.

Funny times ahead.

Enjoy!

Mike

cgracey · 2014-03-27 17:02

Cluso99 wrote: »

PUSHA is possibly WRLONG D/#,PTRA++
PUSHB is possibly WRLONG D/#,PTRB-- because B works in reverse
PUSHX is possibly WRAUX D/#,PTRX++
PUSHY is possibly WRAUX D/#,PTRY--
POPA is possibly RDLONG D,PTRA--
etc

You might like to start a new thread and give us the details of the online editor. I have only partly followed your progress on the P1 thread.

Only PTRY was made to have any reverse behavior (via CALLY/RETY), so the PTRA/PTRB pushes and pops are all normal:

PUSHA D/# is WRLONG D/#,PTRA++
PUSHB D/# is WRLONG D/#,PTRB++
PUSHX D/# is WRAUX D/#,PTRX++
PUSHY D/# is WRAUX D/#,--PTRY

POPA D is RDLONG D,--PTRA
POPB D is RDLONG D,--PTRB
POPX D is RDAUX D,--PTRX
POPY D is RDAUX D,PTRY++

Cluso99 · 2014-03-27 17:18

cgracey wrote: »

Only PTRY was made to have any reverse behavior (via CALLY/RETY), so the PTRA/PTRB pushes and pops are all normal:

PUSHA D/# is WRLONG D/#,PTRA++
PUSHB D/# is WRLONG D/#,PTRB++
PUSHX D/# is WRAUX D/#,PTRX++
PUSHY D/# is WRAUX D/#,--PTRY

POPA D is RDLONG D,--PTRA
POPB D is RDLONG D,--PTRB
POPX D is RDAUX D,--PTRX
POPY D is RDAUX D,PTRY++

Thanks Chip.

When the cog starts, all PTR A/B/X/Y are reset to 0, so we can use PTRX/Y immediately without the need to reset the values???
ie So a PUSHX will put into AUX at $00 and a PUSHY will put into $FF ???

cgracey · 2014-03-27 17:28

Cluso99 wrote: »

Thanks Chip.

When the cog starts, all PTR A/B/X/Y are reset to 0, so we can use PTRX/Y immediately without the need to reset the values???
ie So a PUSHX will put into AUX at $00 and a PUSHY will put into $FF ???

That's all correct about PTRX/PTRY, but you probably just forgot about PTRA being the parameter and PTRB pointing to where the program was loaded or execution began.

Cluso99 · 2014-03-27 17:56

cgracey wrote: »

That's all correct about PTRX/PTRY, but you probably just forgot about PTRA being the parameter and PTRB pointing to where the program was loaded or execution began.

I had when thinking about the stacks.

A different question... when starting a new cog with COGNEW/COGNEWX it returns the cog# in the D operand if the start was successful. If the COGNEWx was preceeded with a TARG instruction would this work...

...
  TARG    <cog>
  COGNEW <startaddr>,<paramadr> WC
  TARGOFF

I presume the TARGOFF will be required if the cog was not started (no cogs available) because in that case, D would not have been written ???

cgracey · 2014-03-27 18:05

Cluso99 wrote: »
I had when thinking about the stacks.

A different question... when starting a new cog with COGNEW/COGNEWX it returns the cog# in the D operand if the start was successful. If the COGNEWx was preceeded with a TARG instruction would this work...
...
  TARG    <cog>
  COGNEW <startaddr>,<paramadr> WC
  TARGOFF 
I presume the TARGOFF will be required if the cog was not started (no cogs available) because in that case, D would not have been written ???

As long as COGNEW D/# uses D and not #, a value will be written, regardless of success or not. So, TARG could be used to redirect the result.

Cluso99 · 2014-03-27 19:08

cgracey wrote: »

As long as COGNEW D/# uses D and not #, a value will be written, regardless of success or not. So, TARG could be used to redirect the result.

Nice! Thanks Chip.

Problems with latest FPGA release

Comments