Intent to remove or modify OBEX C package versions

jazzed

Just wanted to let you know that since it is difficult to tell what enhancements I have made to Tom Rockiki's C version of FSRW, that I am deleting it from OBEX. Tom can choose to republish it if he likes.

The other code I have published there uses ascii-byte array generated representations of other "objects" PASM ... in the future I will be removing the arrays and you will have to provide your own. I have provided a tool for doing this PASM extraction.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

OwenS

Jazzed,

why aren't you assembling the assembly with ICC's assembler? It works fine for Cog code

jazzed

OwenS,
Unless I missed something, I understand that ICC can not take a spin file and create machine code from the PASM section. So, I'm using propellent to create a spin binary and extracting the machine code from there into an array for C to consume. I have no plans to convert PASM into ICC ASM. ICC ASM works fine with it's own definition of course.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Rayman

I was also thinking of using Propellent to create the array...

Wouldn't it be nice if ICC could include a binary file as a resource somehow?
·

ImageCraft

OK guys, give me a hand in understanding this: so you have this .binary file, which is probably a kind of driver code, and you want to be able to just "combine" it with the C program somehow, and have the C program to invoke the function within in another COG?

And in the general cases, we may have multiple .binary files, for different COGs?

Roy Eltham

Yeah, if we could just include a binary file in the project and use it as native cog code to launch, that would be cool.

Something else I would like is a way to designate a cog object (.s compiled to .o as cog native) as only existing long enough to be launched (perhaps even auto launching it), and then it's memory space being released to the stack or allocation heap.

hippy

It comes down to "I want a PASM Assembler which can generate a file ICC can then use".

At the moment the easiest path seems to be to code one's PASM in the PropTool with a dummy PUB Main header, save that as a .binary/.eeprom, run a utility to extract what the PASM image is into a file which forms a pre-initialised byte/long array ICC can access.

I actually like that approach because the dummy PUB Main can actually be a whole load of Spin which allows the PASM code to be tested before its use with ICC or anything else. Ideally then this utility should be able to extract the PASM code itself from any arbitrary .Spin file.

Should be easy enough to wrap that up as a self-contained utility which takes in .Spin and throws out a .h file; Propellent called to compile the .Spin, the utility then extracts the PASM from the resultant .binary, creates a .h file with the array definition in it, and deletes the .binary file ( using Propellent.Dll may be even easier ).

Roy Eltham

There is an assembler that comes with ICC. You create .s files for it and can include them right in the project and use the resultant asm with coginit_native() to get it running in a cog.
I've done this very thing. It's not perfect yet, but close and getting better as we speak.

The syntax is a little bit different from using a spin file, but only in minor ways. You could probably write a simple tool to convert a source .spin with asm into a .s file easily.

Ron Sutcliffe

I don't know what is wrong with spinc.exe by Jazzed it simply works.