PNut improvements request to Chip.

Sapieha · 2013-04-20 02:03

Hi Chip.

I Have one question to You ?

Can You made 2 extra

ORG

directives.

ORGF and ORGH

Examples:

1.

org 0

My COG 1 code
.....
......
.....
......
Last instruction
0000
0000
0000
0000
0000
0000
ORGF XXX

Fills iin $0000_0000 betwen --- Last instruction and ORGF
.....

some more COG 1 code
......
.....
......
$1FF ---- End of COG 1 code

2.

orgH 0
.....
......
.....
......
ORGH $E80

If --- orgH 0 --- omited Start HUB addresses from $E80
ORG 0

My COG 1 code
'''''''''''
''''''''''' Diverse code
'''''''''''
'''''''''''
0000
0000
ORGH ZZZZZ

Fills iin $0000_0000 betwen --- Last instruction and ORGH
'
ORG 0

My COG 2 code
'''''''''''
''''''''''' Diverse code
'''''''''''
'''''''''''

cgracey · 2013-04-20 08:55

What I really need to do, I think, is add a loader that can load up the entire memory. I've been meaning to do this for a while, but I've been onto other issues. I'll try to fix up PNUT soon.

Sapieha · 2013-04-20 09:24

Hi Chip

That are other thing.

BUT that org's I describe have be made us simpler to manage Memory.
If You look in Cluso's code it is many places that we adjust in all possible way -- And it don't work correctly

Every time I add else remove any instruction --- Need recalculate that.

ORG

Shall be as it is

ORGF ---- org with fill unused space with $0 COG
ORGH ---- org with fill unused space with $0 HUB

With That 2 new ORG's - Life have be much easier

THANKS

cgracey wrote: »

What I really need to do, I think, is add a loader that can load up the entire memory. I've been meaning to do this for a while, but I've been onto other issues. I'll try to fix up PNUT soon.

David Betz · 2013-04-20 11:20

cgracey wrote: »

What I really need to do, I think, is add a loader that can load up the entire memory. I've been meaning to do this for a while, but I've been onto other issues. I'll try to fix up PNUT soon.

Hi Chip,

Could you please let me know your plans in this area. I imagine that p2load will be completely abandoned if PNut.exe gets the ability to load all of memory. That's fine but people have asked for more features that I was just about to add today and I don't want to invest a lot of effort in something that won't be needed shortly. Can you describe what you're planning to do and the timeframe?

Edit: Is there any way we could avoid duplicating work and share code? The p2load code is, of course, all open source. Maybe I can expand it to handle the needs of PNut.exe. Could we cooperate on this so we can make faster progress?

Thanks!
David

Sapieha · 2013-04-20 11:24

Hi David.

In first place I think Chip are thinking on compile files that use more as 32K.

We need that to compile Vectors in correct place

BUT

Your's p2load even then have GOOD life.

David Betz wrote: »

Hi Chip,

Could you please let me know your plans in this area. I imagine that p2load will be completely abandoned if PNut.exe gets the ability to load all of memory. That's fine but people have asked for more features that I was just about to add today and I don't want to invest a lot of effort in something that won't be needed shortly. Can you describe what you're planning to do and the timeframe?

Thanks!
David

David Betz · 2013-04-20 11:33

Sapieha wrote: »

Hi David.

In first place I think Chip are thinking on compile files that use more as 32K.

We need that to compile Vectors in correct place

BUT
Your's p2load even then have GOOD life.

Can't PNut already compile code that is larger than 32K? I thought its problem was that it can't load more than 2K of code because it doesn't make use of a second-stage loader and the ROM loader can only load 2K.

Sapieha · 2013-04-20 11:35

Hi David.

PNut --- can compile only to 32K object as it is now

David Betz wrote: »

Can't PNut already compile code that is larger than 32K? I thought its problem was that it can't load more than 2K of code because it doesn't make use of a second-stage loader and the ROM loader can only load 2K.

David Betz · 2013-04-20 11:57

Sapieha wrote: »

Hi David.

PNut --- can compile only to 32K object as it is now

Thanks. I didn't know that. I guess I've never tried to use it to build anything very large. I'm sure that won't be a difficult restriction for Chip to remove.

cgracey · 2013-04-20 13:46

David,

I will ultimately write my own second-stage loader, since it must handle fuse bits and some certain flash-chip protocol (probably Winbond's). I'm not sure when I'll get to this. It's part of a bigger picture that is not yet totally clear to me.

I don't think you'd be wasting your time improving the loader you've already made.

David Betz · 2013-04-20 13:50

cgracey wrote: »

David,

I will ultimately write my own second-stage loader, since it must handle fuse bits and some certain flash-chip protocol (probably Winbond's). I'm not sure when I'll get to this. It's part of a bigger picture that is not yet totally clear to me.

I don't think you'd be wasting your time improving the loader you've already made.

Thanks Chip!

I imagine my loader will eventually have to deal with the fuse bits as well. Is there any way we can produce some common code that could be used by both of us? It seems silly to write the same code twice. I'd be happy to provide you with a library that you can call from PNut to do the loading.

David Betz · 2013-04-20 13:56

cgracey wrote: »

David,

I will ultimately write my own second-stage loader, since it must handle fuse bits and some certain flash-chip protocol (probably Winbond's). I'm not sure when I'll get to this. It's part of a bigger picture that is not yet totally clear to me.

I don't think you'd be wasting your time improving the loader you've already made.

Sorry, I forgot to mention this in my previous message. I have code that will write to the Winbond chip.

cgracey · 2013-04-20 14:05

I'm sure yours would work, but I still want to write my own, as it's going to be intimately tied to the tool I make. I'll share it, for what it's worth, too. Thanks for your offer, though.

David Betz · 2013-04-20 14:22

cgracey wrote: »

I'm sure yours would work, but I still want to write my own, as it's going to be intimately tied to the tool I make. I'll share it, for what it's worth, too. Thanks for your offer, though.

Okay if that's what you want but it seems to me that cross-platform reusable code would be much more useful than "code intimately tied to the tool". I guess it's Roy's job to take the Windows-specific stuff and rewrite it to work on other platforms.

cgracey · 2013-04-20 14:51

David Betz wrote: »

Okay if that's what you want but it seems to me that cross-platform reusable code would be much more useful than "code intimately tied to the tool". I guess it's Roy's job to take the Windows-specific stuff and rewrite it to work on other platforms.

It doesn't have anything to do with Windows. I want to ultimately get my tools running on the chip, itself, and have them independent of all other platforms. That's where I want to go. And I know my approach tends to frustrate others, so I work alone. I've gotten lots of help from people, but it all comes in the form of ideas, not exact code. I just like to write my own, so I know it. It's a weakness and a strength, I suppose.

David Betz · 2013-04-20 14:54

cgracey wrote: »

It doesn't have anything to do with Windows. I want to ultimately get my tools running on the chip, itself, and have them independent of all other platforms. That's where I want to go. And I know my approach tends to frustrate others, so I work alone. I've gotten lots of help from people, but it all comes in the form of ideas, not exact code. I just like to write my own, so I know it. It's a weakness and a strength, I suppose.

If you want to run on the chip itself wouldn't C be a good solution? The code can be made to run either under Windows/Linux/Mac or directly on the Propeller since all of those platforms support C.

cgracey · 2013-04-20 15:10

David Betz wrote: »

If you want to run on the chip itself wouldn't C be a good solution? The code can be made to run either under Windows/Linux/Mac or directly on the Propeller since all of those platforms support C.

It would probably be smarter, but I don't enjoy programming in C, so it doesn't interest me. There's opportunity for others, though, to make C tools.

Too bad there aren't more like me, because maybe Big Pharma could create ProCvoid, or something, to get us over the hump.

David Betz · 2013-04-20 15:23

cgracey wrote: »

It would probably be smarter, but I don't enjoy programming in C, so it doesn't interest me. There's opportunity for others, though, to make C tools.

Too bad there aren't more like me, because maybe Big Pharma could create ProCvoid, or something, to get us over the hump.

Will ProSpinVoid also be available? It may be more profitable. I guess I'm in the wrong place here. Good luck with your on-board tools project.

cgracey · 2013-04-20 16:08

David, I've meant no offense, at all. I wish you wouldn't take any.

Cluso99 · 2013-04-20 16:13

Sapieha wrote: »

Hi Chip

That are other thing.

BUT that org's I describe have be made us simpler to manage Memory.
If You look in Cluso's code it is many places that we adjust in all possible way -- And it don't work correctly

Every time I add else remove any instruction --- Need recalculate that.

ORG
Shall be as it is

ORGF ---- org with fill unused space with $0 COG
ORGH ---- org with fill unused space with $0 HUB

With That 2 new ORG's - Life have be much easier
THANKS

Sapieha,
ORGF can already be done with something similar to this...

                byte    "*"[((_COG_SIZE/4)-$)*4]                 ' filler for cog size (maybe removed to save space)

Chip:
Is there any way to get access to the hub address similar to the $ in cog. Currently in my P2 debugger I have to continually reset the code using ORG 0 so that I can calculate the offsets between two labels (usually one is the current address). My code is LMM PASM handcrafted.

BTW I do understand wanting to do it your way in PASM. I much prefer PASM too. Having it all running on a P2 is totally achievable whereas on the P1 it had some limitations although still achievable. I will watch with interest, and even add to what you do.

David,
P2Load has its' place so please continue to develop it. I am sure it will work with Roy's compiler when done for the P2. Meanwhile, I am using P2Load many times each day when I can spare te time to work on my debugger. Thanks for your work

cgracey · 2013-04-20 16:20

I think you can track hub offset across multiple ORG's by having a final label at the end of each program (but before any RES's) that you multiply by 4 to get the object-code offset for that program. Then you can sum them together to get the offset into the desired ORG section.

David, I, too, appreciate your work, in case you didn't know.

potatohead · 2013-04-20 18:02

David in the wrong place?

I hope not!

I really like P2load, and I will get a nice user document for it done. That will help acceptance.

Maybe my earlier C post didn't make enough sense. I believe in the C efforts. They are progressing well, and on a P2 will prove very capable.

David Betz · 2013-04-20 18:09

potatohead wrote: »

David in the wrong place?

I hope not!

I really like P2load, and I will get a nice user document for it done. That will help acceptance.

Maybe my earlier C post didn't make enough sense. I believe in the C efforts. They are progressing well, and on a P2 will prove very capable.

I'm planning to add the ability to write a bootable image to flash. Not sure about anything after that at this point.

PNut improvements request to Chip.

Comments