gpdasm 0.13.6 alpha question

[Peter Keller]

Hello,

I have a small assembly program for the pic18f4550 that I'm assembling
with gputils. The assembly seems to work fine and I can burn it to the
pic with pk2cmd And things appear to work.

However, when disassembling the program using gpdasm I get funky addresses
for the configuration bits and the EEPROM.

Here is an example:

000000:  ef15  goto 0x2a
000002:  f000
00002a:  ec21  call 0x42, 0
00002c:  f000
00002e:  ec2f  call 0x5e, 0
000030:  f000
000032:  ec3b  call 0x76, 0
000034 - 00008c: all the correct instructions

Then the configuration bits get printed out, but the data sheet says it is
supposed to be at 300000h-3FFFFFh

60000000:  0804  sublw  0x4
60000002:  1e38  comf   0x38, 0x1, 0
60000004:  00ff  reset
60000006:  ff80  dw 0xff80  ;unknown opcode
60000008:  c00f  movff  0xf, 0xf
6000000a:  e00f
6000000c:  400f  rrncf  0xf, 0, 0

Then the EEPROM gets printed out. This contains the valid data, but I have
an org 0xF00000 at the start of the 'de' directives. Why does it end up at
e0000000?

e0000000:  6c42  negf   0x42, 0
# all correct data in here
e000004e:  0000  nop

If I use gpvo to look at the object file which contains the EEPROM data,
I get this:

Section Header
Name                    .org_780000
Address                 0xf00000
Size of Section         80
Number of Relocations   0
Number of Line Numbers  40
Flags                   0x1020
  Executable code.
  Absolute.

Data
f00000:  6c42  negf     0x42, 0
f00002:  6e69  movwf    0x69, 0
f00004:  696b  setf     0x6b, 0x1
f00006:  676e  tstfsz   0x6e, 0x1
f00008:  4c20  dcfsnz   0x20, 0, 0

So the assembly process seems to have done the right thing wrt the object
file. (As far as I know the EEPROM starts at 0xf00000, but the data sheet
doesn't mention an address, and I got that info from the internet).

Here is the entire test.hex file that gpasm produced, maybe it is somehow
wrong?

:020000040000FA
:0400000015EF00F008
:06002A0021EC00F02FECB8
:1000300000F03BEC00F035EC00F03BEC00F017EF8B
:1000400000F0626F0F01806A0F0E0F01C16E070E84
:100050000F01B46E000E0F01926E62511200626FBA
:10006000010E0F01806E62511200626F000E0F01CF
:10007000806E625112000001A00E616FFF0E606F72
:0E008000602F40EF00F0612F3EEF00F0120005
:020000040030CA
:0E0000000408381EFF0080FF0FC00FE00F4005
:0200000400F00A
:10000000426C696E6B696E67204C45442056657280
:1000100073696F6E20302E30200042792070736932
:100020006C6F72644063732E776973632E656475B9
:100030002E20436F707972696768742032303039CE
:100040002E20425344204C6963656E73652E000078
:00000001FF

Any help would be appreciated. Even if it is a bug in one of the tools, I'll
take a crack at fixing it if someone points me in a direction. I'm just
not sure what is *supposed* to happen since I've only started recently
understanding the hex format.

Thank you.

-pete




---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Robert Pearce-3]

On Wed, 11 Mar 2009, Peter Keller <psilord@...> wrote :
>
>Then the configuration bits get printed out, but the data sheet says it is
>supposed to be at 300000h-3FFFFFh
>
>60000000:  0804  sublw  0x4
>60000002:  1e38  comf   0x38, 0x1, 0

That definitely looks wrong - the upper 8 bits of the address seem to
have been shifted left by nine!
>
>Then the EEPROM gets printed out. This contains the valid data, but I have
>an org 0xF00000 at the start of the 'de' directives. Why does it end up at
>e0000000?
>
>e0000000:  6c42  negf   0x42, 0

Again, the upper 8 bits are shifted left by nine....

>If I use gpvo to look at the object file which contains the EEPROM data,
>I get this:
>
<snip correct looking stuff>
>
>So the assembly process seems to have done the right thing wrt the object
>file. (As far as I know the EEPROM starts at 0xf00000, but the data sheet
>doesn't mention an address, and I got that info from the internet).

(The data sheet doesn't quote that address because it's not real, merely
conventional. Unlike the configuration data, the EEPROM can't be
programmed using the tblwt scheme for main programming. Hence the
0xF00000 address offset used in the HEX file is only a convention for
tools, not something imposed by the silicon.)

>
>Here is the entire test.hex file that gpasm produced, maybe it is somehow
>wrong?
>
No, it looks correct to me.

Here's a block starting at 0x00000000 :
>:020000040000FA
>:0400000015EF00F008
>:06002A0021EC00F02FECB8
>:1000300000F03BEC00F035EC00F03BEC00F017EF8B
>:1000400000F0626F0F01806A0F0E0F01C16E070E84
>:100050000F01B46E000E0F01926E62511200626FBA
>:10006000010E0F01806E62511200626F000E0F01CF
>:10007000806E625112000001A00E616FFF0E606F72
>:0E008000602F40EF00F0612F3EEF00F0120005

Now there's a block at 0x00300000 :
>:020000040030CA
>:0E0000000408381EFF0080FF0FC00FE00F4005

And finally some data at 0x00F00000 :

>:0200000400F00A
>:10000000426C696E6B696E67204C45442056657280
>:1000100073696F6E20302E30200042792070736932
>:100020006C6F72644063732E776973632E656475B9
>:100030002E20436F707972696768742032303039CE
>:100040002E20425344204C6963656E73652E000078
>:00000001FF
>
>Any help would be appreciated. Even if it is a bug in one of the tools, I'll
>take a crack at fixing it if someone points me in a direction.

Given what you've posted, it appears gpdasm may be misinterpreting the
"type 04" blocks - the lines of the HEX file that begin ":02000004"

--
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | Windows NT crashed.
message are purely   | I am the Blue Screen of Death.
my opinion. Don't    | No one hears your screams.
believe a word.      |

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Keller]

Hello,

On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:

> On Wed, 11 Mar 2009, Peter Keller <psilord@...> wrote :
> >
> >Then the configuration bits get printed out, but the data sheet says it is
> >supposed to be at 300000h-3FFFFFh
> >
> >60000000:  0804  sublw  0x4
> >60000002:  1e38  comf   0x38, 0x1, 0
>
> That definitely looks wrong - the upper 8 bits of the address seem to
> have been shifted left by nine!

I just noticed something else too, suppose the addresses were right, and it
looked like this:

300000:  0804  sublw  0x4
300002:  1e38  comf   0x38, 0x1, 0

I would read that (from left to right) as being:

300000: 08
300001: 04
300002: 1e
300003: 38

But, as far as I can determine, there seems to be an endian swap, and it
really should look like this:

300000:  0408
300002:  381e

leading to:

300000: 04
300001: 08
300002: 38
300003: 1e

Both gpdasm and gpvo do this, and sadly, pk2cmd does this also when I
ask it for the configuration bits. I must say, this screwed me up for a
good long time since I thought the processor was in a certain mode when
it wasn't! Are the other sections printed out like this too?

How would one make gdasm and gpvo smarter to actually print out the
configuration bits is a much more human readable manner?

> (The data sheet doesn't quote that address because it's not real, merely
> conventional. Unlike the configuration data, the EEPROM can't be
> programmed using the tblwt scheme for main programming. Hence the
> 0xF00000 address offset used in the HEX file is only a convention for
> tools, not something imposed by the silicon.)

Could I get a bit more clarification on where the EEPROM addresses are on
PICs in general? It seems a hard thing to pin down.

> Given what you've posted, it appears gpdasm may be misinterpreting the
> "type 04" blocks - the lines of the HEX file that begin ":02000004"

I see. Think this may get fixed before the new release?

Also, is there a better place to report this stuff, like in the wiki or
something? Do I need an account? I'm interested in hacking on gputils
(as my time permits) since I'm using it for several projects of mine.

Thank you.

-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Robert Pearce-3]

On Thursday 12 March 2009, Peter Keller wrote:

>
> I just noticed something else too, suppose the addresses were right, and it
> looked like this:
>
> 300000:  0804  sublw  0x4
> 300002:  1e38  comf   0x38, 0x1, 0
>
> I would read that (from left to right) as being:
>
> 300000: 08
> 300001: 04
> 300002: 1e
> 300003: 38
>

No, that would be a wrong reading. The PIC is little-endian, so the byte at
0x300000 is the lower byte of the word.

> But, as far as I can determine, there seems to be an endian swap, and it
> really should look like this:
>
> 300000:  0408
> 300002:  381e
>
> leading to:
>
> 300000: 04
> 300001: 08
> 300002: 38
> 300003: 1e
>

No, you're still parsing that as big-endian. The first listing, where the WORD
at 0x300000 is 0804, matches your last listing where the BYTE at 0x300000 is
04. This is just how the PIC works. That's why the byte at 0x300002 is called
CONFIG2L and the one at 0x300003 is CONFIG2H.

>
> How would one make gdasm and gpvo smarter to actually print out the
> configuration bits is a much more human readable manner?
>
They're doing the right thing for what they're intended to do. The
instructions interpreted by gpdasm are all word values stored in the flash
LSB first.

>
> Could I get a bit more clarification on where the EEPROM addresses are on
> PICs in general? It seems a hard thing to pin down.
>
That's not an entirely meaningful question - the EEPROM is in a separate
address space. It's a bit like asking where 38 South Road is on High Street -
it isn't, it's somewhere else. Since the HEX file format doesn't allow for
multiple address spaces, MicroChip decided on a convention (or several
different conventions, in fact) for mapping the EEPROM address space into
out-of-range normal address space so that programmers can load it. These
conventions are therefore programmer related rather than device related. You
can usually find them in a comment in the "In Circuit Serial Programming"
guide for the family. The 0xF00000 address is used for most (all?) 18F
devices, while 0x2100 is generally used for mid-range (16F) devices (but note
that mid-range devices use word addressing).

Cheers,
Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Peter Keller wrote:
> Also, is there a better place to report this stuff, like in the
> wiki or something? Do I need an account? I'm interested in hacking
> on gputils (as my time permits) since I'm using it for several
> projects of mine.

You're in exactly the right place! :)


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

On Thu, Mar 12, 2009 at 11:29 AM, Peter Stuge <peter@...> wrote:
> Peter Keller wrote:
>> Also, is there a better place to report this stuff, like in the
>> wiki or something? Do I need an account? I'm interested in hacking
>> on gputils (as my time permits) since I'm using it for several
>> projects of mine.
>
> You're in exactly the right place! :)

But if nothing happens to it quickly, it is more easily found from the
http://sourceforge.net/projects/gputils tracker.

Marko

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Keller]

On Thu, Mar 12, 2009 at 09:17:46AM +0000, Rob Pearce wrote:

> On Thursday 12 March 2009, Peter Keller wrote:
> > 300000:  0804  sublw  0x4
> > 300002:  1e38  comf   0x38, 0x1, 0
> >
> > I would read that (from left to right) as being:
> >
> > 300000: 08
> > 300001: 04
> > 300002: 1e
> > 300003: 38
> >
> No, that would be a wrong reading. The PIC is little-endian, so the byte at
> 0x300000 is the lower byte of the word.

That definitely explains my misread, thanks.

> > Could I get a bit more clarification on where the EEPROM addresses are on
> > PICs in general? It seems a hard thing to pin down.
> >
> That's not an entirely meaningful question - the EEPROM is in a separate
> address space. It's a bit like asking where 38 South Road is on High Street -
> it isn't, it's somewhere else. Since the HEX file format doesn't allow for
> multiple address spaces, MicroChip decided on a convention (or several
> different conventions, in fact) for mapping the EEPROM address space into
> out-of-range normal address space so that programmers can load it. These
> conventions are therefore programmer related rather than device related. You
> can usually find them in a comment in the "In Circuit Serial Programming"
> guide for the family. The 0xF00000 address is used for most (all?) 18F
> devices, while 0x2100 is generally used for mid-range (16F) devices (but note
> that mid-range devices use word addressing).

I get it now, thank you for the explanation.

-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[David Barnett-3]

On Thu, Mar 12, 2009 at 12:07 AM, Peter Keller <psilord@...> wrote:

> Also, is there a better place to report this stuff, like in the wiki or
> something?

It's always good to have a ticket in the bug tracker for any issues, but the
mailing list is a good place, too.

We do have a wiki, btw: http://gputils.wiki.sourceforge.net/

Do I need an account? I'm interested in hacking on gputils
> (as my time permits) since I'm using it for several projects of mine.

If you're interested in problems like this then there's plenty to work on.
Have a look at the wiki (feel free to add/edit), then look through the bugs
and feature requests on SourceForge and see if anything catches your
attention.

I've been thinking long and hard about how to make gputils development less
painful, so if you have any thoughts, put them on the wiki and/or email me.
I'm not sure how much something like doxygen would help, but I've noticed in
my experience that it's hard to mentally trace data through the program, and
most of our remaining bugs seem to be caused by stubborn design limitations.

David

[Peter Keller]

On Thu, Mar 12, 2009 at 07:31:04PM -0400, David Barnett wrote:
> If you're interested in problems like this then there's plenty to work on.
> Have a look at the wiki (feel free to add/edit), then look through the bugs
> and feature requests on SourceForge and see if anything catches your
> attention.

I suppose I'd be interested in writing codes for a regression test suite,
mostly because for whatever reason I find that fun, it teaches me all
of the wierd edge cases in the tools, and it always benefits a project.
What does your current test framework look like?

I'd also like to make the output of gpdasm(especially)/gpvo more human
readable. For example, actually showing me the real configuration bits
(instead of a 16-bit value) and what it means to a human when they are
on or off, having the disassembler show an ascii dump of the EEPROM
sections as a comment (so you could reassemble it without trouble),
things like that.

> I've been thinking long and hard about how to make gputils development less
> painful, so if you have any thoughts, put them on the wiki and/or email me.
> I'm not sure how much something like doxygen would help, but I've noticed in
> my experience that it's hard to mentally trace data through the program, and
> most of our remaining bugs seem to be caused by stubborn design limitations.

Are the maintainers and developers opposed to more radical ideas, like
using sqlite to store all of the data for all of the processors/eeproms,
or having a centralized repository for prcessor data, and you can ask
gputils tool to query it to get new processor defines and shove it into
a per user cache which augments the database downloaded when you got the
installation? Then if there was a good enough specification language
for a processor (which doesn't appear to be *that* much information
from looking at the source), then people could hand write a processor
description for somthing new that shows up, submit it via a tool, just
like when you put in a CD into audacity or something, and see if there
is one already there?  If you're the first, it gets labeled "experimental
definition" until it is vetted by a group or somthing and becomes cannon.

I've written some compilers in my life too, maybe I could help with the
lexer/parser situation gputils finds itself in.

Those are the types of things I'm thinking about...

Of course, all of this is dependant on the time I have available. :)
You could get a lot out of me in a month, or nothing for a year. It's
how it goes.

Thanks.

-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[David Barnett-3]

On Thu, Mar 12, 2009 at 10:51 PM, Peter Keller <psilord@...> wrote:

> I suppose I'd be interested in writing codes for a regression test suite,
> mostly because for whatever reason I find that fun, it teaches me all
> of the wierd edge cases in the tools, and it always benefits a project.
> What does your current test framework look like?

That's a great place to start. We have some real issues with our testing
framework (which is just a few shell scripts), so do whatever you'd like to
the test system as long as we're still testing everything our current tests
do. Have a look at gputils/gpasm/testsuite/README, and there are also
testsuite directories in gputils/gplink and gputils/gputils (for gpdasm,
gpvo, etc.). I just wrote up some info on the wiki to get you started if
that's where you want to start (
http://gputils.wiki.sourceforge.net/RegressionTests).


> I'd also like to make the output of gpdasm(especially)/gpvo more human
> readable. For example, actually showing me the real configuration bits
> (instead of a 16-bit value) and what it means to a human when they are
> on or off, having the disassembler show an ascii dump of the EEPROM
> sections as a comment (so you could reassemble it without trouble),
> things like that.

You could take a look at FR #1897673 ("Disassemble configuration memory").
It seems pretty manageable.

Are the maintainers and developers opposed to more radical ideas...

Depends on the idea. I think we're fairly open to new approaches, but
backwards compatibility is pretty important to us. I'd say we have a lot of
leeway with any implementation details that aren't very visible to the
users.

> ...like using sqlite to store all of the data for all of the
> processors/eeproms,
> or having a centralized repository for prcessor data, and you can ask
> gputils tool to query it to get new processor defines and shove it into
> a per user cache which augments the database downloaded when you got the
> installation?

With this upcoming release, we've knocked out most of our processor
compatibility issues. We'll be able to stay in sync with MPLAB as far as
supported processors, so unless you're talking about a lot of customized
non-Microchip devices, that particular problem has been solved already.

My pet radical ideas for gputils are making banking/paging instructions
obsolete and adding a relocatable bit type. However, MPASM/MPLINK
compatibility is my top priority, so for any extensions we make to Microchip
assembly syntax, I'd really like to add an "output canonical assembly"
option to gpasm that would dump Microchip-compatible assembly. It's great to
have selling points over MPASM, but I don't want to lock people into using
gputils if possible.

I've written some compilers in my life too, maybe I could help with the
> lexer/parser situation gputils finds itself in.

We can collaborate closely on that if you'd like. I got started on it once
but never got back to a clean state. I think I still have a copy of some
half-finished changes if you'd like to wade through them, but it might be
best to start from scratch.

I was working on untangling a separate lexer/parser for the preprocessor,
because the way we try to expand macros and #defines in the same pass as the
assembler seems to be a big part of our problems.

Let me know if you need something from me to get going if/when you get time.
You can put nitty-gritty details on the wiki or email me directly if you'd
like.

Good luck.
David

[Ralph Corderoy]

Hi,

> We have some real issues with our testing framework (which is just a
> few shell scripts), so do whatever you'd like to the test system as
> long as we're still testing everything our current tests do.

Just want to mention http://www.gnu.org/software/dejagnu/manual/ here in
case it's useful.

Cheers,


Ralph.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Keller]

On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
> Given what you've posted, it appears gpdasm may be misinterpreting the
> "type 04" blocks - the lines of the HEX file that begin ":02000004"

So, I inspected the readhex() function and followed what it was doing during
the gpdasm, and eventually found that it led to here:

MemBlock * i_memory_new(MemBlock *m, MemBlock *mbp, unsigned int base_address)
{
  unsigned int base;

  /* added by psilord */
  printf("i_memory_new raw base_address = 0x%x\n", base_address);

  base = (base_address >> I_MEM_BITS) & 0xFFFF;

  /* added by psilord */
  printf("i_memory_new cooked base_address = 0x%x\n", base);

  mbp->memory = (unsigned int *)calloc(MAX_I_MEM, sizeof(unsigned int));
  mbp->base   = base;

  do {

    if((m->next == NULL) || (m->next->base > base)) {
      /* Insert after this block */
      mbp->next = m->next;
      m->next   = mbp;
      return mbp;
    }

    m = m->next;
  } while(m);

  assert(0);

  return NULL;
}


Here is some sample output:

i_memory_new raw base_address = 0x30000000
i_memory_new cooked base_address = 0x6000

i_memory_new raw base_address = 0xf0000000
i_memory_new cooked base_address = 0xe000

So, from what I can gather, when readhex is supplying to i_memory_put the
address to which it wants to write, the base address gets miscomputed in the
above function when it is a "new" address in a different memblock.

Given the portion of code in gpdasm.c:dasm() which shifts left the
base address of the mem block by one bit of the processor is of class
PROC_CLASS_16E, maybe when i_memory_new is called and the state.class
is PROC_CLASS_16E, it should shift right the base address by one more
bit so it doesn't get truncated by the 0xFFFF? I hacked a test of that by
hand hand it seemed to do the right thing. However, the state variable
doesn't seem to be used in gpmemory.c, and I fear if I add that dependancy
in there I'm doing something wrong since it wasn't already in there. ;)

Any ideas?

Thanks.

-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

I too have been trying to wrap my head around these memory issues.

Which is rather difficult as there seem to be things which are not
obvious and there are little comments to explain what is the design
choice. Does any developer have any feelings the code is better off
without such comments?

This particular bug seems to be in the gpreadhex.c. It combines two
bytes into one word, hence dividing each address in .hex by two to get
the address for MemBlock access. However it does not do this for the
.hex record 04 value which sets the page. Therefore the data after
this records ends up into addresses twice too large in MemBlock. Of
course the values in page 0 are not affected.

My current understanding is it would be clearer if MemBlock was
changed to be byte storage. It would then record separately for each
byte whether they have been used or not and these .hex file readers
and few other places need not be so complex to support partial words.

Instead of scattering the processor class specifics in accessing
MemBlock around, I'd rather use some object oriented design and access
MemBlock through the processor class. The processor class would then
uniformly solve these addressing issues, as well as byte order issues.
This design change easily blows up because it could replace also a
number of other switch-case and if-else constructs around the code
with single call to processor class function.

It'd take some thought.

Maybe a simple fix to this gpdasm problem could be made before such
design changes. I attach a patch. Robert, does this solve the problem?

Marko

On Tue, Mar 17, 2009 at 9:04 AM, Peter Keller <psilord@...> wrote:

> On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
>> Given what you've posted, it appears gpdasm may be misinterpreting the
>> "type 04" blocks - the lines of the HEX file that begin ":02000004"
>
> So, I inspected the readhex() function and followed what it was doing during
> the gpdasm, and eventually found that it led to here:
>
> MemBlock * i_memory_new(MemBlock *m, MemBlock *mbp, unsigned int base_address)
> {
>  unsigned int base;
>
>  /* added by psilord */
>  printf("i_memory_new raw base_address = 0x%x\n", base_address);
>
>  base = (base_address >> I_MEM_BITS) & 0xFFFF;
>
>  /* added by psilord */
>  printf("i_memory_new cooked base_address = 0x%x\n", base);
>
>  mbp->memory = (unsigned int *)calloc(MAX_I_MEM, sizeof(unsigned int));
>  mbp->base   = base;
>
>  do {
>
>    if((m->next == NULL) || (m->next->base > base)) {
>      /* Insert after this block */
>      mbp->next = m->next;
>      m->next   = mbp;
>      return mbp;
>    }
>
>    m = m->next;
>  } while(m);
>
>  assert(0);
>
>  return NULL;
> }
>
>
> Here is some sample output:
>
> i_memory_new raw base_address = 0x30000000
> i_memory_new cooked base_address = 0x6000
>
> i_memory_new raw base_address = 0xf0000000
> i_memory_new cooked base_address = 0xe000
>
> So, from what I can gather, when readhex is supplying to i_memory_put the
> address to which it wants to write, the base address gets miscomputed in the
> above function when it is a "new" address in a different memblock.
>
> Given the portion of code in gpdasm.c:dasm() which shifts left the
> base address of the mem block by one bit of the processor is of class
> PROC_CLASS_16E, maybe when i_memory_new is called and the state.class
> is PROC_CLASS_16E, it should shift right the base address by one more
> bit so it doesn't get truncated by the 0xFFFF? I hacked a test of that by
> hand hand it seemed to do the right thing. However, the state variable
> doesn't seem to be used in gpmemory.c, and I fear if I add that dependancy
> in there I'm doing something wrong since it wasn't already in there. ;)
>
> Any ideas?
>
> Thanks.
>
> -pete
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[David Barnett-3]

Marko, that sounds right to me. Our handling of byte vs. word addressing is
ugly throughout the system, and it definitely seems like we need to give
byte order and address type an explicit representation.

If you come up with something, I'd love to see it.

David

On Tue, Mar 17, 2009 at 5:02 AM, Marko Kohtala <marko.kohtala@...>wrote:

> I too have been trying to wrap my head around these memory issues.
>
> Which is rather difficult as there seem to be things which are not
> obvious and there are little comments to explain what is the design
> choice. Does any developer have any feelings the code is better off
> without such comments?
>
> This particular bug seems to be in the gpreadhex.c. It combines two
> bytes into one word, hence dividing each address in .hex by two to get
> the address for MemBlock access. However it does not do this for the
> .hex record 04 value which sets the page. Therefore the data after
> this records ends up into addresses twice too large in MemBlock. Of
> course the values in page 0 are not affected.
>
> My current understanding is it would be clearer if MemBlock was
> changed to be byte storage. It would then record separately for each
> byte whether they have been used or not and these .hex file readers
> and few other places need not be so complex to support partial words.
>
> Instead of scattering the processor class specifics in accessing
> MemBlock around, I'd rather use some object oriented design and access
> MemBlock through the processor class. The processor class would then
> uniformly solve these addressing issues, as well as byte order issues.
> This design change easily blows up because it could replace also a
> number of other switch-case and if-else constructs around the code
> with single call to processor class function.
>
> It'd take some thought.
>
> Maybe a simple fix to this gpdasm problem could be made before such
> design changes. I attach a patch. Robert, does this solve the problem?
>
> Marko
>
> On Tue, Mar 17, 2009 at 9:04 AM, Peter Keller <psilord@...> wrote:
> > On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
> >> Given what you've posted, it appears gpdasm may be misinterpreting the
> >> "type 04" blocks - the lines of the HEX file that begin ":02000004"
> >
> > So, I inspected the readhex() function and followed what it was doing
> during
> > the gpdasm, and eventually found that it led to here:
> >
> > MemBlock * i_memory_new(MemBlock *m, MemBlock *mbp, unsigned int
> base_address)
> > {
> >  unsigned int base;
> >
> >  /* added by psilord */
> >  printf("i_memory_new raw base_address = 0x%x\n", base_address);
> >
> >  base = (base_address >> I_MEM_BITS) & 0xFFFF;
> >
> >  /* added by psilord */
> >  printf("i_memory_new cooked base_address = 0x%x\n", base);
> >
> >  mbp->memory = (unsigned int *)calloc(MAX_I_MEM, sizeof(unsigned int));
> >  mbp->base   = base;
> >
> >  do {
> >
> >    if((m->next == NULL) || (m->next->base > base)) {
> >      /* Insert after this block */
> >      mbp->next = m->next;
> >      m->next   = mbp;
> >      return mbp;
> >    }
> >
> >    m = m->next;
> >  } while(m);
> >
> >  assert(0);
> >
> >  return NULL;
> > }
> >
> >
> > Here is some sample output:
> >
> > i_memory_new raw base_address = 0x30000000
> > i_memory_new cooked base_address = 0x6000
> >
> > i_memory_new raw base_address = 0xf0000000
> > i_memory_new cooked base_address = 0xe000
> >
> > So, from what I can gather, when readhex is supplying to i_memory_put the
> > address to which it wants to write, the base address gets miscomputed in
> the
> > above function when it is a "new" address in a different memblock.
> >
> > Given the portion of code in gpdasm.c:dasm() which shifts left the
> > base address of the mem block by one bit of the processor is of class
> > PROC_CLASS_16E, maybe when i_memory_new is called and the state.class
> > is PROC_CLASS_16E, it should shift right the base address by one more
> > bit so it doesn't get truncated by the 0xFFFF? I hacked a test of that by
> > hand hand it seemed to do the right thing. However, the state variable
> > doesn't seem to be used in gpmemory.c, and I fear if I add that
> dependancy
> > in there I'm doing something wrong since it wasn't already in there. ;)
> >
> > Any ideas?
> >
> > Thanks.
> >
> > -pete
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>

[Peter Keller]

On Fri, Mar 13, 2009 at 03:44:20PM +0000, Ralph Corderoy wrote:
> > We have some real issues with our testing framework (which is just a
> > few shell scripts), so do whatever you'd like to the test system as
> > long as we're still testing everything our current tests do.
>
> Just want to mention http://www.gnu.org/software/dejagnu/manual/ here in
> case it's useful.

So what things do you *need* the test framework to do that it doesn't do
now? After reading the wiki page, the only thing I see so far is that you
could catagorize failures in such a manner as to easily decide on whether
or not you should halt a release depending upon what broke. Anything else
you'd specifically like? Html/human output of results? That sort of thing?

I personally have no objections to using dejagnu (though, is tcl/tk going
to be around a while? It seems to be falling out of favor with the hacker
community.), does it support a particularly nice feature that you folks
want incorporated?

Also, what should I check out to do my work? The trunk? Any words of
wisdom before I start tinkering with stuff?

Thank you.

-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[David Barnett-3]

On Tue, Mar 17, 2009 at 8:50 PM, Peter Keller <psilord@...> wrote:

> On Fri, Mar 13, 2009 at 03:44:20PM +0000, Ralph Corderoy wrote:
> > > We have some real issues with our testing framework (which is just a
> > > few shell scripts), so do whatever you'd like to the test system as
> > > long as we're still testing everything our current tests do.
> >
> > Just want to mention http://www.gnu.org/software/dejagnu/manual/ here in
> > case it's useful.
>
> So what things do you *need* the test framework to do that it doesn't do
> now? After reading the wiki page, the only thing I see so far is that you
> could catagorize failures in such a manner as to easily decide on whether
> or not you should halt a release depending upon what broke.

Yeah, it's not unusable as it is, just really confusing for people who
haven't used it before (due to the gpasm.mchip failures). It doesn't *need*
a complete overhaul. It's whatever you feel like doing, if anything.

Anything else you'd specifically like? Html/human output of results? That
> sort of thing?

Nothing specific. I wasn't trying to burden you with a bunch of
requirements, just to suggest some ideas. I'd like them to be easy to run,
whatever you read that to mean, but I'd say to dive in and tinker with what
we have, see if you notice anything else you'd like to work differently, and
see how far you can get with it.

I personally have no objections to using dejagnu (though, is tcl/tk going
> to be around a while? It seems to be falling out of favor with the hacker
> community.)...

I personally don't have a strong preference. My impression of tcl/tk is that
it's never been huge in the mainstream, but that it has a wide following for
testing in the *nix community because the expect tool works so well (or so I
hear).


> ...does it support a particularly nice feature that you folks want
> incorporated?

I only suggested it because Craig (I think) suggested it in the TODO doc.
Ralph might be able to answer that for us.


> Also, what should I check out to do my work? The trunk?

I always work out of trunk/gputils. The top-level directories (under trunk)
are fairly self-contained.


> Any words of wisdom before I start tinkering with stuff?

Yeah, first off, the tests are your friend. Don't fret about whether you've
broken something, just run the tests. If they pass and you still think
something's screwy, try adding one that fails. Second, think by coding.
Don't outsmart yourself trying to plan ahead for everything. Just get an
idea, go with it, and see how far you can get with it.

Good luck!
David

[Ralph Corderoy]

Hi,

> > ...does it support a particularly nice feature that you folks want
> > incorporated?
>
> I only suggested it because Craig (I think) suggested it in the TODO
> doc.  Ralph might be able to answer that for us.

Yes, tcl's dieing a slow death, tk is the more long-lasting offshot.  I
mentioned DejaGnu because it may offer more than the existing framework,
and it is quite common so people popping their heads into this project
for a few nights may find it easier to contribute.

Buildbot can be useful to build and test upon commit, including if
there's different configuration options.  http://buildbot.net/trac

Cheers,


Ralph.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

I've been looking into byte vs. word addressing in gputils when ever I
have had some spare time. That is not very often, so the progress has
been very slow.

Since it now seems I'll eventually end up with some sort of a patch,
I'll let you know I'm working on it and report my current idea for it.

I've changed MemBlock to byte storage. I'll use the byte address for
everything internally. For instruction handling I always treat an
instruction as two bytes and for instruction writing and reading there
will be functions that write and read the two bytes. Instruction
memory usage is therefore also managed byte by byte. When ever an
instruction address is needed (in COFF or COD headers or messages for
ROM sections, or in assembly) it'll see if its not PIC16E and divide
byte address by two.

I've also turned processor class into a structure that holds what is
needed to remove a number of processor class switch statements around
the code.

Not everything compiles yet, and I expect it'll take some time to
clean it up and get it to pass the tests again. If someone likes to
take a look and comment or continue on it, I can send the patch in
whatever state it happens to be.

Marko

On Tue, Mar 17, 2009 at 3:32 PM, David Barnett <daviebdawg@...> wrote:

> Marko, that sounds right to me. Our handling of byte vs. word addressing is
> ugly throughout the system, and it definitely seems like we need to give
> byte order and address type an explicit representation.
>
> If you come up with something, I'd love to see it.
>
> David
>
> On Tue, Mar 17, 2009 at 5:02 AM, Marko Kohtala <marko.kohtala@...>wrote:
>
>> I too have been trying to wrap my head around these memory issues.
>>
>> Which is rather difficult as there seem to be things which are not
>> obvious and there are little comments to explain what is the design
>> choice. Does any developer have any feelings the code is better off
>> without such comments?
>>
>> This particular bug seems to be in the gpreadhex.c. It combines two
>> bytes into one word, hence dividing each address in .hex by two to get
>> the address for MemBlock access. However it does not do this for the
>> .hex record 04 value which sets the page. Therefore the data after
>> this records ends up into addresses twice too large in MemBlock. Of
>> course the values in page 0 are not affected.
>>
>> My current understanding is it would be clearer if MemBlock was
>> changed to be byte storage. It would then record separately for each
>> byte whether they have been used or not and these .hex file readers
>> and few other places need not be so complex to support partial words.
>>
>> Instead of scattering the processor class specifics in accessing
>> MemBlock around, I'd rather use some object oriented design and access
>> MemBlock through the processor class. The processor class would then
>> uniformly solve these addressing issues, as well as byte order issues.
>> This design change easily blows up because it could replace also a
>> number of other switch-case and if-else constructs around the code
>> with single call to processor class function.
>>
>> It'd take some thought.
>>
>> Maybe a simple fix to this gpdasm problem could be made before such
>> design changes. I attach a patch. Robert, does this solve the problem?
>>
>> Marko
>>
>> On Tue, Mar 17, 2009 at 9:04 AM, Peter Keller <psilord@...> wrote:
>> > On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
>> >> Given what you've posted, it appears gpdasm may be misinterpreting the
>> >> "type 04" blocks - the lines of the HEX file that begin ":02000004"
>> >
>> > So, I inspected the readhex() function and followed what it was doing
>> during
>> > the gpdasm, and eventually found that it led to here:
>> >
>> > MemBlock * i_memory_new(MemBlock *m, MemBlock *mbp, unsigned int
>> base_address)
>> > {
>> >  unsigned int base;
>> >
>> >  /* added by psilord */
>> >  printf("i_memory_new raw base_address = 0x%x\n", base_address);
>> >
>> >  base = (base_address >> I_MEM_BITS) & 0xFFFF;
>> >
>> >  /* added by psilord */
>> >  printf("i_memory_new cooked base_address = 0x%x\n", base);
>> >
>> >  mbp->memory = (unsigned int *)calloc(MAX_I_MEM, sizeof(unsigned int));
>> >  mbp->base   = base;
>> >
>> >  do {
>> >
>> >    if((m->next == NULL) || (m->next->base > base)) {
>> >      /* Insert after this block */
>> >      mbp->next = m->next;
>> >      m->next   = mbp;
>> >      return mbp;
>> >    }
>> >
>> >    m = m->next;
>> >  } while(m);
>> >
>> >  assert(0);
>> >
>> >  return NULL;
>> > }
>> >
>> >
>> > Here is some sample output:
>> >
>> > i_memory_new raw base_address = 0x30000000
>> > i_memory_new cooked base_address = 0x6000
>> >
>> > i_memory_new raw base_address = 0xf0000000
>> > i_memory_new cooked base_address = 0xe000
>> >
>> > So, from what I can gather, when readhex is supplying to i_memory_put the
>> > address to which it wants to write, the base address gets miscomputed in
>> the
>> > above function when it is a "new" address in a different memblock.
>> >
>> > Given the portion of code in gpdasm.c:dasm() which shifts left the
>> > base address of the mem block by one bit of the processor is of class
>> > PROC_CLASS_16E, maybe when i_memory_new is called and the state.class
>> > is PROC_CLASS_16E, it should shift right the base address by one more
>> > bit so it doesn't get truncated by the 0xFFFF? I hacked a test of that by
>> > hand hand it seemed to do the right thing. However, the state variable
>> > doesn't seem to be used in gpmemory.c, and I fear if I add that
>> dependancy
>> > in there I'm doing something wrong since it wasn't already in there. ;)
>> >
>> > Any ideas?
>> >
>> > Thanks.
>> >
>> > -pete
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: gnupic-unsubscribe@...
>> > For additional commands, e-mail: gnupic-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: gnupic-unsubscribe@...
>> For additional commands, e-mail: gnupic-help@...
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...