The TJZ immediate branch can only go +/- 255 instructions. It's unlikely that cog and hubexec code will be that close together.
Even that doesn't work crossing back from hubexec.
I've worked it out I think. When relative branching from hubexec back into cogexec/lutexec, it does similar to going to hubexec. When going to hubexec all addresses are longword scaled. Eg: A relative address resolved to $401 actually lands you at hubram address $404. That generally works fine as long as hub code is longword aligned.
Well, doing the same again going back to cogram means each increment steps four cogram locations at a time! It can only land on addresses that have least two bits as zero.
But, not so good for a code developer who may add methods without testing them...
Well, one's not supposed to add untested methods, yet we all do it anyways...
OTOH, Spin is really not good for writing self-contained test code (unless you're just testing the public interface of an object).
Eric has been walkout for about a week now, which is unusual. Historically he has been incredibly responsive to bug reports, often spinning a new version of FlexGUI within hours. I’m hoping he is buried in a project and making some really obscene $$$.
@ersmith We miss ya, ol’ Bean! Write when you can!
I wondered why Eric hadn't been online for a while as well so I sent him email and got a response from his wife saying he had been taken to the hospital a week ago. He is still there waiting for the doctors to determine the cause of his illness. She said she wasn't sure when he would be back.
@ersmith I'm putting this up here for when you are "back in the saddle again". There isn't any sense of urgency here.
There is an interesting issue I found in FlexBASIC 4.1.3 on a Win10 machine targetting a P2-EVAL Rev B board. If you (accidently) create two SUBs with the same name in the same file, you will get a "child killed: segmentation violation" error when you try to compile it. Here is the output of one such attempt:
"d:/Flex2Gui/flexgui/bin/fastspin" -2 -l -O1 -I "d:/Flex2Gui/flexgui/include" -I "d:/Flex2Gui/flexgui/P2 Libs" "d:/Flex2Gui/flexgui/P2 Libs/GPS-RTC-Serial-TestP2.bas"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 4.1.3 Compiled on: Feb 5 2020
child killed: segmentation violation
Finished at Thu Mar 5 14:09:34 2020
This is very clearly a case of the programmer shooting himself squarely in the foot (I'm quite good at that), but it would be helpful to have an error thrown that is a bit more descriptive if its possible.
I haven't heard anything from either Eric or his wife lately although I sent her the comments from this forum after I posted about his illness and she said he was touched. I'll post as soon as I hear anything.
Thanks everyone for your good wishes. I'm still in hospital but feeling much better. We hope this trend will continue and I'll be out of here soon. Until then my wifi access is a bit wonky so please forgive delays getting back to you.
Glad you're doing well, Eric! You must be tempted, somewhat, to get a laptop going in the hospital. As you get better, your brain will hunger for something to do.
Comments
Fastspin says
error: tjnz branch crosses LUT/COG boundary
when 9-bit immediate is not big enough for jump and nothing to do with boundary crossing.
Oddly, there is no Fastspin error when I have too many closing ")".
I think it just generates NOPs until back to address $400 where it will fetch from the FIFO again. Just does weird stuff, depending on the offset.
Actually, I just noticed this in garryj's code:
Guess the trick is to leave off the comma at the end of the line...
Well, doing the same again going back to cogram means each increment steps four cogram locations at a time! It can only land on addresses that have least two bits as zero.
EDIT: Removed some dross
EDIT2: Improve lutram code copy generalisation
This is fine for a code user, who is just using proven code.
But, not so good for a code developer who may add methods without testing them...
Well, one's not supposed to add untested methods, yet we all do it anyways...
OTOH, Spin is really not good for writing self-contained test code (unless you're just testing the public interface of an object).
The local variables in a method I was continuously calling were preserved between calls.
But, when I made a copy of this method (with slightly different name),
the local variables were no longer preserved.
Obviously, these variables should be in a VAR section (they are now).
Still, I'm surprised it worked the way it was...
PS: ersmith: Hope you're not sick again!
Ditto that!
Eric has been walkout for about a week now, which is unusual. Historically he has been incredibly responsive to bug reports, often spinning a new version of FlexGUI within hours. I’m hoping he is buried in a project and making some really obscene $$$.
@ersmith We miss ya, ol’ Bean! Write when you can!
Thanks for the update. I tried emailing him and got no reply.
Hope they figure out what's up and get him on the road to recovery soon.
Wishing you a speedie recovery. We miss you.
There is an interesting issue I found in FlexBASIC 4.1.3 on a Win10 machine targetting a P2-EVAL Rev B board. If you (accidently) create two SUBs with the same name in the same file, you will get a "child killed: segmentation violation" error when you try to compile it. Here is the output of one such attempt: This is very clearly a case of the programmer shooting himself squarely in the foot (I'm quite good at that), but it would be helpful to have an error thrown that is a bit more descriptive if its possible.
No worries about delays in replies, your health is more important.
Eric, you are simply amazing! I really hope to meet you some day and shake your hand!
Get better, Ol’ Bean. We miss you!