Subj : BAJA OpCode suggestion
To : Digital Man
From : Angus Netfoot
Date : Mon Jan 03 2000 12:24 am
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
