I wholeheartedly agree, mnemonics as mentioned are much easier to read and teach/learn.
At this point though, I think the current open process is going to give that short shrift. My memory is a bit hazy, but IIRC even the multiple addressing modes on the 6502 were all pretty clear.
Mnemonics are instantly understandable, whereas conditional symbols are.. not.
The 'fun' part of this is going to be lessened I think, because hey, we can type one less letter?
Clear descriptive mnemonics are a lot easier to learn (and read) when working with code that a single one with a bunch of non descriptive conditional symbol characters attached.
Example A___ = Absolute mode, R___ = Relative mode, I___ indirect mode, etc.
They can be grouped together in the documentation with the differences identified. With some standard labeling this is clear across multiple instructions (common theme).
Since a major target here is educational use making things as easy as possible for beginners would seem to be a priority. Gurus already know this stuff like the back of their hands and sometimes forget how something so easy for them can be very hard for a new programmer.
I agree wholeheartedly, but I would prefer expanded mnemonics as a compiler option.
To make things easier to use as they are now, I would like to see an eventual auto help function in the tool... sort of like a commented autocomplete function, without the "complete"... hit a keycombo and it pops up a little help window... or leave the help window in the corner and have it constantly updating itself with each new line of code.
Yup. This works for me too. I wonder why I'm not seeing the same with my code snippet...
Ah! I found my problem. I was using @ozpropdev's showhex code, which does not save/restore C/Z. Once I changed that, I got the values I was expecting. So, ignore my rambling...
I agree wholeheartedly, but I would prefer expanded mnemonics as a compiler option.
To make things easier to use as they are now, I would like to see an eventual auto help function in the tool... sort of like a commented autocomplete function, without the "complete"... hit a keycombo and it pops up a little help window... or leave the help window in the corner and have it constantly updating itself with each new line of code.
Anything else? I think chip was going to start a thread to document this stuff, but as he hasn't yet, I figured I'd try to consolidate at least a few of the items (the ones I can remember).
(note: there appears to be some hub-related streamer issues that I did not include above, since I don't know if the exact problem has been identified yet. I'm only listing the items above which are specifically known at this time. Hopefully we can get an interim update for the above items while we continue to troubleshoot additional issues.)
Anything else? I think chip was going to start a thread to document this stuff, but as he hasn't yet, I figured I'd try to consolidate at least a few of the items (the ones I can remember).
(note: there appears to be some hub-related streamer issues that I did not include above, since I don't know if the exact problem has been identified yet. I'm only listing the items above which are specifically known at this time. Hopefully we can get an interim update for the above items while we continue to troubleshoot additional issues.)
Got all these, too.
I went in to see what trouble there was with the SETRDL/SETWRL-related events and I had forgotten to use an index in one place. Got that all fixed.
There are now three timers: CT1, CT2, CT3.
The masked WRLONG is now done by the WMLONG instruction, which works with SETQ/SETQ2 to write masked (don't write $FF bytes) data from cog/lut into hub.
I also added two new events and interrupt sources:
WAITRLE/POLLRLE - read lut end (lut location $1FF was read)
WAITWLE/POLLWLE - write lut end (lut location $1FF was written)
Perhaps these can be used as software interrupts.
Just waiting for the DE2-115 compile to finish, then I'll do the DE0-Nano compiles.
I intended to get the new file out last night, but the DE2-115 was taking so long to compile that I was falling asleep. I went to bed at the 1.5 hour point. I'll be out there within an hour and I will see if it finished. I still have to do the DE0-Nano compiles, but they only take about 7 minutes each.
I intended to get the new file out last night, but the DE2-115 was taking so long to compile that I was falling asleep. I went to bed at the 1.5 hour point. I'll be out there within an hour and I will see if it finished. I still have to do the DE0-Nano compiles, but they only take about 7 minutes each.
I also added two new events and interrupt sources:
WAITRLE/POLLRLE - read lut end (lut location $1FF was read)
WAITWLE/POLLWLE - write lut end (lut location $1FF was written)
Perhaps these can be used as software interrupts.
What would be the point of software interrupts? Can't the program just do an indirect jump somewhere? I thought software interrupts were only useful on processors with memory protection.
Can the LUT be used as a stack? If so, these events would be useful for detecting stack overflow/underflow and automatically swapping more stack out to or in from hubram.
Would an hubram out-of-bounds event be more useful, like jmg suggested?
Loopy, all Chip is providing are the binary image files (.rbf, .pof, .jic). They are built for the specific boards and I can't imagine there is any way to port them ot another board. You'd need the actual verilog source so you could take care of pin assignments and such and then rebuild them for the target boards.
Comments
Here's what i'm seeing Led0,1 not lit = zero bit
led2,3 lit = one bit
I wholeheartedly agree, mnemonics as mentioned are much easier to read and teach/learn.
At this point though, I think the current open process is going to give that short shrift. My memory is a bit hazy, but IIRC even the multiple addressing modes on the 6502 were all pretty clear.
Mnemonics are instantly understandable, whereas conditional symbols are.. not.
The 'fun' part of this is going to be lessened I think, because hey, we can type one less letter?
Yup. This works for me too. I wonder why I'm not seeing the same with my code snippet...
To make things easier to use as they are now, I would like to see an eventual auto help function in the tool... sort of like a commented autocomplete function, without the "complete"... hit a keycombo and it pops up a little help window... or leave the help window in the corner and have it constantly updating itself with each new line of code.
Ah! I found my problem. I was using @ozpropdev's showhex code, which does not save/restore C/Z. Once I changed that, I got the values I was expecting. So, ignore my rambling...
I agree, however rather than discuss here Seairth is correct and this thread should focus on the important stuff.
* PNUT fix for SUBX
* Fix RET to set C/Z properly
* Fix hub memory events
* Separate lock events from pin events
* Add one (or two?) more timers
* Enhance CORDIC (mindrobots)
* Dedicated "JMP D" instruction
* Correct/add if_00, if_1x, etc. (ozpropdev)
Anything else? I think chip was going to start a thread to document this stuff, but as he hasn't yet, I figured I'd try to consolidate at least a few of the items (the ones I can remember).
(note: there appears to be some hub-related streamer issues that I did not include above, since I don't know if the exact problem has been identified yet. I'm only listing the items above which are specifically known at this time. Hopefully we can get an interim update for the above items while we continue to troubleshoot additional issues.)
"I've got the read/new result overlap case covered. I expect to have new FPGA files out today. Just need to compile for all 4 boards. "
Good to know! I haven't been reading that thread, so I missed that announcement.
Got these covered.
Got all these, too.
I went in to see what trouble there was with the SETRDL/SETWRL-related events and I had forgotten to use an index in one place. Got that all fixed.
There are now three timers: CT1, CT2, CT3.
The masked WRLONG is now done by the WMLONG instruction, which works with SETQ/SETQ2 to write masked (don't write $FF bytes) data from cog/lut into hub.
I also added two new events and interrupt sources:
WAITRLE/POLLRLE - read lut end (lut location $1FF was read)
WAITWLE/POLLWLE - write lut end (lut location $1FF was written)
Perhaps these can be used as software interrupts.
Just waiting for the DE2-115 compile to finish, then I'll do the DE0-Nano compiles.
Cool.
I was wondering about an off-chip software interrupt ?
Very similar to those LUT, but for
HUB exceeded ->software interrupts.
That would allow a trap for uninitialized pointer (fill memory first with 0xff), and should also allow a form of DLL load from much larger memory.
No hurry.
What would be the point of software interrupts? Can't the program just do an indirect jump somewhere? I thought software interrupts were only useful on processors with memory protection.
Can the LUT be used as a stack? If so, these events would be useful for detecting stack overflow/underflow and automatically swapping more stack out to or in from hubram.
Would an hubram out-of-bounds event be more useful, like jmg suggested?
I will take a look and try some things.. then report back.
WMLONG added - like WRLONG, but doesn't write $FF bytes, works with SETQ/SETQ2
I think I'm lost... I thought SETQ2 was used to not write $FF bytes... What does WMLONG do that's different?
I'm working on the docs now, to clear this up.
SETQ2 now means LUT transfer for RDLONG/WRLONG/WMLONG.
WMLONG means 'write masked long (s)', and it works like WRLONG, but skips writing any $FF bytes.
If it is now explicitly & only LUT, then it probably needs renaming, to something clearer ?
PNUT is still compiling WAITCNT.
REPLUT D/#
For consistency, make an alias for SETQ to the cog variant:
REPCOG D/#
I just checked and you're right, sort of.
It just thinks you've declared a symbol. No code is generated.
Seems like it'd be the same...
It goes like this:
Before:
SETQ2 with RDxxx would read data into LUT
SETQ2 with WRxxx would write cog data to hub, except for $FF
Now:
SETQ2 with RDxxx reads data into LUT
SETQ2 with WRxxx writes data from LUT
SETQ with WMLONG writes cog data to hub, except for $FF
SETQ2 with WMLONG writes LUT data to hub, except for $FF
Maybe I'd change setq2 to setqlut ... I don't know...