 | | RE: Double echo
|
| (...) Yup. Dave tells me he is working on integrating the speedier loader into NQC or even making standalone loaders by themselves... Sergey, which features do you REALLY want/need for the next release. I'm doing the following... 1. ECHO_ON/ECHO_OFF (...) (25 years ago, 27-Oct-99, to lugnet.robotics.rcx.pbforth)
| | | | | Re: Double echo
|
| (...) Standalone loader would be nice. (...) Well, the most important, of course, is the stack bug. BTW, what about multitasker? How many cells would you recommend to allocate? Should be it checked by HAT word or not? (...) Sure, I would like to (...) (25 years ago, 27-Oct-99, to lugnet.robotics.rcx.pbforth)
| | | | | RE: Double echo
|
| (...) Yes, it should. The issue is that you never really know if the stack will blast through the 256 byte boundary, unless HAT checks it. You generally allocate small stacks, so HAT could be modified to FORCE the data stack to start at the boundary (...) (25 years ago, 28-Oct-99, to lugnet.robotics.rcx.pbforth)
| | | | | Re: Double echo
|
| Hi Ralph, (...) Means that we will have to waste memory a lot... Do you know how the standard LEGO firmware works? Does it allocate stack frame for each task or may be it's not an issue at all? (...) Yes, "4th" was always my favourite. Only question (...) (25 years ago, 28-Oct-99, to lugnet.robotics.rcx.pbforth)
| | | | | RE: Double echo
|
| (...) There are no "tasks really, just a big loop that executes a bunch of opcodes...I'm paraphrasing here. The memory waste issue isn't that big a deal. The average distance to a boundary is 128 bytes, right. Say we allocate a 32 element data stack (...) (25 years ago, 28-Oct-99, to lugnet.robotics.rcx.pbforth)
| |
