Float and PASM? And some other generic noob asm questions.
TJHJ
Posts: 243
So probably a really dumb question, but I was beginning my leaning for PASM, And it brought up a thought that I am not sure how to deal with.
Innately PASM is incapable of dealing with floating point math?
As such there is no real PASM equivalent of an method call, in which you can call a ASM function from a library of (example) floating point functions, that are stored in main ram like we call from objects in spin? ( Just wanted to make sure I wasnt missing this some how.)
When a cognew(@PASMcode, @Var) is called to go to assembly the result that gets calculated and finally stored in Var, is subject to a few delays. Lets assume that the calculation ends somewhere before the cog acess window is up. Does the program wait for the window to open and wait for a sync to main ram, where Var is located or do we need to perform some sort of protection to ensure that this happens?
Then if the program then enters a loop, will Var be correctly updated the next window even though the asm program is off doing another calculation?
Thank you for the time as always,
TJ
Innately PASM is incapable of dealing with floating point math?
As such there is no real PASM equivalent of an method call, in which you can call a ASM function from a library of (example) floating point functions, that are stored in main ram like we call from objects in spin? ( Just wanted to make sure I wasnt missing this some how.)
When a cognew(@PASMcode, @Var) is called to go to assembly the result that gets calculated and finally stored in Var, is subject to a few delays. Lets assume that the calculation ends somewhere before the cog acess window is up. Does the program wait for the window to open and wait for a sync to main ram, where Var is located or do we need to perform some sort of protection to ensure that this happens?
Then if the program then enters a loop, will Var be correctly updated the next window even though the asm program is off doing another calculation?
Thank you for the time as always,
TJ
Comments
2) There is nothing equivalent to a method call. There's only the simple JMPRET instruction and the macros CALL and RET which use JMPRETs.
3) Cogs are independent little computers and the main (hub) memory works a bit like an I/O device as far as the cog is concerned. The COGNEW downloads a small program to the cog, sets the equivalent of a couple of switches on a control panel (the @Var), and starts it running. The program in the cog does something and along the line may do some I/O to I/O pins or to the hub memory. If it's to the hub memory and the hub is busy, the cog is frozen until the hub is ready. Nothing else happens automatically (except maybe with the cog's counters and video generator, but that's another topic).
Regarding @Var and your question about updating it ... Nothing happens automatically. There has to be code in your cog program to do it.
So I was on the right line of thought, Just wanted to make sure before I started pounding my head at the wall going why why why .... again
There is a way and that is LMM ( Large Memory Model ) coding which allows PASM to be executed from main Hub memory but it does require some effort to use it.
You cannot just move PASM to Hub and execute it, some things you cannot do, some things have to be coded differently, you have to add what is usually called a kernel to help support what that code needs to do, and you need to write the code which executes the LMM PASM and deals with calls into and returns back again. On top of that you have to write your own LMM code to do what you need, there are no libraries written like there are pre-written Spin objects.
One thing I've thought would be useful is for someone to create an LMM kernel and framework which would allow people to simply move PASM to Hub memory and execute it "as is" as if it were in Cog, that is, allowing self-modifying code and emulating everything as a Cog would.
There's some complexities to that but nothing insurmountable. The biggest issue would be if two Cogs were running the same LMM PASM and both updated that PASM in Hub memory as they executed. That may not be an issue in practice or a limitation we would have to live with. It's not perfect, it won't run as fast as code modified for kernel calls would but would undoubtedly help those who don't want to get into the business of designing or writing kernels of their own.
I have too many other projects planned to develop that further any time soon but have doe some preliminary proof of concept which determined it would work.