Thread: Converting MINI-BASIC in MASM over to C++?

"Is there is some other way then to dynamically detect endianess? I would rather not use a macro, if at all possible."

*shrug*

One non-portable solution is as good as any other. At any rate, if you consistently use the swapping/independence routines you've provided I can patch the `config.h' and your implementation later to determine host endianness from a macro falling back on the aliasing if it isn't set.

"Well, what you describe is essentially the functionality they already provide."

Yes. You've implemented something very similar for the provided routines of the compiler and codes of the virtual machine. What I'm suggesting is hooks for outside influence to be applied before failure--the handler triggered for unknown functions. (I don't like the idea of having to crack open the implementation to add something simple.)

"But maybe you can give me an example of how that would work so that I can see it more clearly?"

*shrug*

As I ask people I work for: how would you like it to work? My first thoughts provided something reasonably simple.

Code:

void alert_emitter(compiler & c)
{
   // ???
   c.emit_interrupt_header(MAGIC_NUMBER);
   // ???
   c.emit(/*???*/);
   // ???
   c.emit_interrupt_cleanup(MAGIC_NUMBER);
   // ???
}

Code:

void alert_handler(interpreter & c)
{
   // ???
   int i = pop();
   // i haven't examined the source in
   // enough detail to know how you
   // are handling string data I
   // just assume you have primitives
   // available to track compiled strings
   std::pair<bool, std::string> value;
   value = c.string_from_resource(i);
   if(value.first)
   {
      messagebox("alert", value.second);
   }
   // ???
}

Code:

// from compiler `compile_line'
// after "else if( skip( "PRINT" ) || skip( "?" ) )"
// ???
if(valid_entity(text) && emit_fun = find(emitter.begin(), emitter.end(), entity_name(text))
{
   // ???
   (*emit_fun)(*this);
   // ???
}
// ???

Code:

// from interpreter `initialize_table'
   table[ minibasic::INTERRUPT ] = &interpreter::INTERRUPT;
// from &interpreter::INTERRUPT
   int handler_entity = pop();
   if(handler_fun = find(handler.begin(), handler.end(), handler_entity))
   {
      // ???
      handler_fun(*this);
      // ???
   }

"Do you mean to detect user intervention, or something else?"

Actually, I was referring to the possibility of a particular build not providing a particular function. I was talking about a "future proof" file format so additions/expansions could be flagged in a new file format that old versions could still read... if only to explain what was missing.

"Additions/changes are welcome, though."

I'll have to post my notes later. I haven't transcribed them from my currently soggy brain. (As I've already said, I do so very hate the WIN32API.) At the very least, beyond the above referenced additions/expansions flags, I would also add a endianness flag--to support native loading for the interpreter--and an area for baked `peek'/`poke' area. (I'm not entirely sure this is necessary. I've never really examined the original assembler. It does allow for some clever tricks if the "line editor" portion works as I think it does in the original.)

"Just wanted to add that though I've updated some of the code, I won't be posting any more updates to the repo until we've figured out what I'm doing wrong."

You've done some weird things to the source.

Try the following steps and let me know if any additional changes will push to the hosted repository without problems or errors. (You should backup your local repository.)

There is no problem to be honest. I wasn't wrong really, but I wasn't right either. All three of us were working from different "heads". You just need to merge them together before you push another set for the default snapshot to show the latest source from everyone. This isn't strictly necessary yet since we don't have a true "release". In other words, you can safely continue working from your repository--and its "head"--and Mats his repository--and its "head"--pushing the sets back as you make changes. You can merge the heads with remarkable ease. (Use "hg head" to list the various "heads" associated with the current repository.) Actually, what I've show below is probably not even the best way, but after a few tests I'm almost positive it works--regardless of what other approaches may be available. It is significantly faster and easier than what I did the first time around.

1): hg pull https://[email protected]/matsp/minibasic/ -r 14
2): hg merge -r 12
3): hg commit -u sebastiani -m "merging heads 12 & 16"
4): hg merge -r 14
5): hg commit -u sebastiani -m "merging heads 14 & 17"

When you are done "hg head" should list one "changeset"--marked 18--with two parents.

"I think it has to do with the truncated directory name problem I had earlier."

I don't think so, but that has caused an odd problem in that grabbing a fresh copy shows both "experimental" directories. You should definitely delete that "MINIBA~1" folder before you commit another change.

Soma

(I'm not editing my post because I'm afraid "cboard" will somehow lose my post as it has in the past.)

I'll take a moment to explain what I mean by "baked" area.

I think the original "line editor" portion allows you to directly input commands which affect whatever program is currently loaded--whatever program is executed by "RUN".

Well, you could, presumably, build a few structures in advance--to save execution time once the interpreter/application is actually running--by loading and saving the "freeplay" independently of the program source. (Later associating the relevant image with a particular source.)

Soma