RE: BAJA OpCode suggestion
BY: Digital Man to Angus Netfoot on Fri Dec 17 1999 02:17 pm

As an alternative to the POKE idea, there is EXEC_STR as in something like:

EXEC_STR <string to execute> <start offset> <flags>

The first problem I see with EXEC_STR is the NUL-terminated string issue. Wouldn't be able to execute an IF_TRUE DO_SOMETHING END_IF, for example.
So, perhaps an EXEC_BUF with a length argument. sprintf() could still be used to build the buffer however.

:) I never thought of the null-byte problem. EXEC_BUF sounds like an ideal way to circumvent it. There may be other problems that have not come to mind as yet. I have been thinking about POKE for a while, but the EXEC_BUF idea is a relatively new one here.

Some things will have to be decided. For example, if, within your buffer you code something like

GOTO My_Label

Would that refer to My_Label _within_ the buffer, or to a My_Label outside
the buffer and within the calling module? Declaring My_Label within a
buffer itself is probably tricky, so maybe I should have used

GOTO 45 # offset 45

instead of a named label. Anyway, you get my point. If you have an END_CMD
in a buffer that you EXEC_BUF, should there also be a CMD_HOME in that buffer or will it refer to a CMD_HOME in the calling module?

If I do something like this, creating a CMDSHELL.INC (Baja equivalent for cmdshell.h) would improve the readability considerably:

sprintf str "%c%cTEST\0%c" CS_IF_TRUE CS_PRINT CS_ENDIF
exec_buf str 8

That would certainly be easier than having to look up the hex for each opcode you planned to use. I used to program the Z80 in hex from memory, but that
was a loonnng time ago!

NOP, POKE and PEEK could do a lot. A data buffer is probably not necessary if you could just label a group of NOPs (perhaps a Baja function to
simplify the syntax, however), but it should be made clear to programmers that a block of bytes defined in that manner are CODE bytes and if they're to be used as data, proper precautions should be taken to avoid inadvertent execution.

Yes, this would allow a lot of extra flexibility with a relative minimum of
new opcodes for you to implement. BAJA Programmers would then have the
ability to very forcefully shoot themselves in the foot, and will have to
take all the usual precautions against doing so. :)

EXEC_BUF could be pretty cool too, but would require more work in SBBS.EXE. Since you can't "insert" opcodes into the current module image, it would have to create a temporary module image to execute the buffer. While it would be faster and more convenient than creating .BIN files on the fly,
it would in reality be a very similar implementation.

I imagined that this was the more difficult approach. If you set up a
separate module image, can it still resolve the variables in the calling
module as local? Or would it have to refer to them as GLOBAL INT/STR as per
a separate .BIN file? I suspect that a module calling EXEC_BUF to manipulate it's own (IOW the callers) variables is likely to be a fairly common theme.

If you use a separate module image, that answers my questions WRT the use
of CMD_HOME and CMD_END and similar matters.

Since NOP/POKE/PEEK have the most flexibility, I'll code them first and leave EXEC_BUF for a later effort.

I am keen to see it in action! Err... What were you thinking of doing WRT
the addressing of the PEEKed/POKEd data? At or relative to a label?

A combined STRUPR/CRC32 is a no-brainer and is a good idea (CRC32UPR?).
It would leave the original variable case intact too.

Not essential at all, but might ease things for the BAJA programmer a bit.
You could call it VAR_ADDR or something like that, since it essentially computes the "address" of a variable, but CRC32UPR is probably better,
since there is no reason not to use it for other purposes that are
unrelated to addressing variables.

---
þ Synchronet þ telnet://talamasca-bbs.com http://www.talamasca-bbs.com