Length of Spin/C binary?

Unsoundcode

Hi all, bytes 9 and 8 of a Spin ".binary" file indicate the length of the program data, high byte/low byte respectively as far as I am aware.

1. am I correct in thinking the above
2. does a SIDE binary use those same bytes for length
3 is downloading the number of bytes indicated by bytes 9 and 8 all that is required by the Propeller or should the entire file be downloaded
4 if there is any variation to these rules how would it be indicated in the binary file

Thanks

Jeff

SRLM

Sidestepping your question a bit, with PropGCC there are two external tools that you can use: propeller-elf-size and propeller-elf-image-size.

jazzed

Unsoundcode wrote: »

Hi all, bytes 9 and 8 of a Spin ".binary" file indicate the length of the program data, high byte/low byte respectively as far as I am aware.

1. am I correct in thinking the above
2. does a SIDE binary use those same bytes for length
3 is downloading the number of bytes indicated by bytes 9 and 8 all that is required by the Propeller or should the entire file be downloaded
4 if there is any variation to these rules how would it be indicated in the binary file

Thanks

Jeff

The only time that a propeller-gcc C program binary has the SPIN format is when it is converted using the propeller-load to a .binary file. Otherwise it uses the industry standard .elf file format (a .elf file can be much bigger than a .binary because of symbol information, but still have the same code/data). The values in the SPIN binary have different meanings. I don't recall them at the moment, but the stack start bytes 14 and 15 better approximate SPIN program size because it is the end of code+data+8 bytes.

SimpleIDE displays the total size of a C program in the status bar.

Unsoundcode

Thanks SRLM, I don't think that is what I need really.

What I need is to be able to look at the binary of a "Propeller program" and be able to determine the length of the file and also determine how many bytes get downloaded, or I should say, the minimum number of bytes to download.

I also need to know if the same rule applies for all Propeller programs.

I don't want to use a third party program to view the binary, I want to take the binary as a file and programmatically determine its size.

thanks

Jeff

Unsoundcode

Hi Jazzed, so you can take a C program and use "propeller load" to produce the equivalent of a SPIN binary?

Jeff

David Betz

Unsoundcode wrote: »

Thanks SRLM, I don't think that is what I need really.

What I need is to be able to look at the binary of a "Propeller program" and be able to determine the length of the file and also determine how many bytes get downloaded, or I should say, the minimum number of bytes to download.

I also need to know if the same rule applies for all Propeller programs.

I don't want to use a third party program to view the binary, I want to take the binary as a file and programmatically determine its size.

thanks

Jeff

FYI, the programs that SRLM mentioned are not third party programs. They are part of the Parallax Propeller GCC offering.

jazzed

Unsoundcode wrote: »

Hi Jazzed, so you can take a C program and use "propeller load" to produce the equivalent of a SPIN binary?

Jeff

Yes. propeller-load -s gcc.elf

It is a long time feature of propeller-load. This is done automatically in the new, unreleased, version of SimpleIDE. Waiting for feedback from Parallax before posting that.

Unsoundcode

Thanks guys, FYI I am transferring binary and text files using FTP on my local network onto an iPad using TechBasic which is mentioned in another thread or two.

I am just working out the various options I need to consider, knowing the file size in advance of transferring seems like it would be a useful piece of info.

Jeff

Dave Hein

Can't you just use the file size reported by the OS?

SRLM

Unsoundcode wrote: »

Thanks SRLM, I don't think that is what I need really.

What I need is to be able to look at the binary of a "Propeller program" and be able to determine the length of the file and also determine how many bytes get downloaded, or I should say, the minimum number of bytes to download.

I also need to know if the same rule applies for all Propeller programs.

I don't want to use a third party program to view the binary, I want to take the binary as a file and programmatically determine its size.

thanks

Jeff

Did you try what I posted? As it turns out, the tools that I posted do exactly what you're asking for: built in tools to programmatically determine the download size.

user@desktop:~/$ propeller-elf-size main.gamma.elf 
   text	   data	    bss	    dec	    hex	filename
  19448	   3164	   8000	  30612	   7794	main.gamma.elf
user@desktop:~/$ propeller-elf-image-size main.gamma.elf 
hub:   30612 bytes
user@desktop:~/$ propeller-load -r main.gamma.elf 
Propeller Version 1 on /dev/ttyUSB0
Loading main.gamma.elf to hub memory
22612 bytes sent                  
Verifying RAM ... OK
user@desktop:~/$ 

The download size is just text + data.

But I should point out that download size is misleading, and what I consider a "mis-feature": we actually care about "dec" size, which is the actual size of our program.

ps: the .elf size is 41689 bytes.

Unsoundcode

Hi David Hein, part of my original question was

is downloading the number of bytes indicated by bytes 9 and 8 all that is required by the Propeller or should the entire file be downloaded

when I look at a Prop binary with Proptool I can see its total size is 65535 bytes, I'm thinking the OS will also see a 65535 file size.

So if for example I have 10 program files of a tutorial with each of the Programs 2000 bytes in length and if all that is required to download to the Prop is the 2000 bytes then thats 20000 compared to 655350, ~3% of the original which is a considerable economy.

I would think that the above is ok but I have not had that question answered as yet.


SRLM, I appreciate your detailed explanation of "elf" , unfortunately I don't know what elf is atm. I also don't think it will be necessary if every variation of a Prop binary contains the file size.

The idea on the server side is to drag and drop the binaries into an FTP server folder and not worry about that end of things. I am using Windows OS and a IIs FTP server so in my case I am using no additional software aside from what comes with the OS. A different OS would use a different FTP server and I don't think that presents any serious issues.

Having a FTP server and folder on a local network should be fairly easy to standardize with any operating system so all that is needed at the receiving end is to grab the file and copy it to the sandbox, which is what I am already doing. I am trying to determine if I can optimize the procedure and secondly if I can handle every Prop binary using the same method.

It's not a problem to create a 64K fixed size buffer and read the entire file if that is what is recommended.

thanks

Jeff

Dave Hein

I don't think a *.binary file would ever be larger than 32K. A binary file only contains the code and DAT data. VAR data and the stack are not included in a binary file since VAR data is always initialized to zero and the stack is uninitialized except for the first few bytes. Maybe you are referring some other file format, such as an eeprom file. An eeprom file contains the initialized VAR and stack data, and is always 32K in size. You could use the word contained in bytes 8 and 9 to get the size that a binary file would be. However, if you only send this part you will be missing the few bytes that make of the initial stack frame. It's probably better to just work with the *.binary file format.

Unsoundcode

Thank you David, you are touching on the part that was concerning me.

The files I have been refering to as of now have had the .binary extension and were created using the Proptool, there is an alternate option to create the same "binary" but with the .eeprom extension, do these two formats differ?

Anyway looking at the length that bytes 8 and 9 specify I can see that beyond that value there is usually 4 or 5 bytes that may be what you refer to as stack which makes me think I am misunderstanding what is required during a Prop download. Maybe I should just keep the file in its entirety and be done with it.

thanks

Jeff

Dave Hein

If you are using the .binary from the Prop Tool it should not be 64K in size as you stated. The file should be exactly the same size as the value in bytes 8 and 9. Your OS should report the filesize to be the same as the value in bytes 8 and 9. So you don't need to even look at those bytes, and you can use the size reported by your OS. If this is not the case, please post one of your 64K files so we can understand what it is your looking at.

Unsoundcode

Thanks all for bearing with me on this, I now understand things better than I did.

David I was looking at the "object info" file thinking that was the file that got saved to disk. I don't know what I was thinking it must have been a senior moment. When I looked at the file size on the PC it basically answered the questions I had, sorry you had to tell me twice.

The FTP is really cool, I think it's going to be a good app.

thanks

Jeff