This wouldn't be a 100% architecturallly acurate interpreter. It will let you modify your source while it's executing though to track down workflow issues and constants and stuff, and even keep making changes to your incorrect algorithms without having to constantly recompile or restart the interpreter, but real debugging will need a debugger still.
Posted on 2001-10-05 16:35:48 by _Shawn
what about custom macros? won't it choke on that?
further more isn't this 'overkill'? it doesn't take that long to rebuild things does it?

If we could build it in a webserver then we'd have Asm Server Pages :alright:

I edited your last option a bit :grin:
Posted on 2001-10-05 17:01:31 by Hiroshimator
I'm gonna work on it anyway... & you can't stop me... so NAna NAna NA :tongue: So I guess i vote don't care
-------------------------------
Hiro, yes it's definitely overkill... & so's having psychedelic colors & drag-n-drop on any ide that doesn't mean that there isn't a niche for it anyway. Actually, there are tons of reasons for NOT doing it & only a few FOR doing it.
---------------
Anywho, this is all smoke & mirrors until it gets done. Can't prove to you the why of it until I/we stop blowing smoke :grin:
Posted on 2001-10-05 17:31:19 by rafe
If we could build it in a webserver then we'd have Asm Server Pages


Funny enough I just decided I wanted to implement AHP (Assembly Hypertext Preprocessor) in the webserver I'm writing for HTTPFT (file transfer program) :grin: .
But not in the same manner as you mean, it will be nothing special, it will be a combination of HTML and special codes that can call parts of normal code, written in asm of course.. I created it to make a good combination of easy to edit HTML code and some kind of scripting/executable code.

_Shawn: about your idea, I discussed it with NaN already like he said in the other post...
Actually I don't know if I want such a parser.
Every additional layer onto 'pure assembler' (whatever that may be :)) you loose control and you're moving to a higher level language...
Okay, I am not writing code in hex, and yes I'm using MASM's IFs and ELSEs which are not perfectly optimized but I can see what happens and I know what MASM will make of it.
The objects.inc for our OOP project also shows exactly what happens, and while I was first sceptic about macros (mostly about their speed), I now see they are really powerfull and actually quite fast. On the other hand, it could make life easier to have some higher level things the parser can handle... But I'm probably not going to use it...
I'm happy with what MASM has to offer and with macros you can add a lot of functionality.
It's a personal opinion.. Some people may like it, some may not..
Let's wait for the poll results :)

Thomas
Posted on 2001-10-05 17:37:03 by Thomas
Yeah, it probly would choke on macros, I suppose that leaves Ernie and Thomas?? out of the equation with their OOP stuff. Seriously, there's a way to overcome that and where there's a will, there's a way.


Thanks,
Shawn
Posted on 2001-10-05 17:38:03 by _Shawn
People are misunderstanding the interpreter. There have been times when trying to track down a bug and tweak for the right constand or make changes until the mathmatics came out properly means GPF's or change then compile and run then crash then compile and run. If it can be run in an interpreter, it will allow you to "Preview" your program and make those changes on the fly and then compile and run it once you've worked out the issues.

Ya'll may not use it but I will.


Thanks,
Shawn
Posted on 2001-10-05 17:41:09 by _Shawn
it would be cool to be able to do that. Even cooler would be to have special debug functions
may starting with ;Debug
like ;DebugMessageBox "text" :)

that only execute in the interpreter like that. No more worries about including debug/test code
Posted on 2001-10-05 17:55:09 by Hiroshimator
Its not that I think the idea is without merit but it has some very big problems. A compiler effectively converts human coded text to binary code and it has enough tests to ensure that the conversion works within a set of rules, usually related to what will actually work.

An assembler already does that within a set of rules but if you layer it, you lose the method of testing if something works correctly.

To a reasonable extent you can correct this problem by building enough libraries to encapsulate a lot of code and then use some well written macros to make them a lot easier to use but you are shifting to a compiler by doing this.

What you have to look at is if a compiler will already do it better. Its easy enough to write code that a compiler will beat if you have not done it well or it is a difficult algorithm but layering assembler code rather than building a compiler directly leaves you open to wasting your time.

Still, I don't like to take the fun out of anybodies effort so don't let a preference for some good hex get in the way of writing a new toy, variation and flexibility is still where the action is as long as it delivers the goods.

Regards,

hutch@pbq.com.au
Posted on 2001-10-06 02:46:54 by hutch--
What can a interpreter do that a debugger can't? A debugger sounds like a lot less work, even if you choose to hide the fact that it really is a debugger (meaning you show the user's code, not the disasm) I think it's be less work. And another thing, the way the Pentium chips handle opcodes is better documented then the way MASM handles your commands. And macro's wouldn't be a problem if you know the source to a program (this is a cheap solution however :) )

Anyway, if I'm being stupid tell me :)... and good luck.
Posted on 2001-10-06 07:31:28 by Qweerdy
Qweerdy, Good question & one I seriously considered before I started on this Quixotic quest. Hutch is correct this is a BIG project. I may not be up to the task. Here's how my twisted logic went... I wanted to learn about asm & effcient programming & change to things on the fly. Debuggers will let you do that in a rather limited way. I also want to have at my fingertips optimization info & other info not presented in classical debuggers like cache state etc. Debuggers are excellent at machine state not so good at on the fly changes or partial program fragments & they're no good about trying code frags on different chips etc. So then I got the idea of writing the uber-debugger geared toward asm. Note that there's a bit of interpreter in every debugger to start with & by the time I got done thinking about the god's-gift-to-debuggers project I realized that there was little debugger left & mostly interpreter. Logical chioce, start from the ground up w/ interpreter.

Please note: that I firmly beleive in learning asm, even tho I'm currently writing perl & c/c++ & sql at work I believe that asm is truly helping me be a better programmer in those areas. I need a windmill to tilt at because just reading up wasn't getting me any good at it. For some it's games (HE) for others it's OSs still others sorts (hutch--) for me it's this project. written so as the modular parts may possibly have wider applicability. I'm not really looking for converts just yet & it may wind up being total crap when I'm done... but the journey will have been fun & worth it.
Posted on 2001-10-06 12:59:50 by rafe
Good word rafe. You summed it up. Peronsally, I know that there have been times in my quest with MASM that I've spent code-run-error-code-run-error-code-run-error-repeat until I finally got some constant correct, or figured out that I forgot an instruction, or had them in the wrong order or had an extra instruction. I gets annoying after a while when it's a small change but you have to reassemble every change.

To me, the interpreter allows me to do what a debugger won't. It allows me to break into the source code of the program, step by step execute my assembly instructions, figure out exactly what instruction or block of instructions is causing the error, make changes, specially if it's just a Windows constant or something, and keep going or keep setting the currently executing code back a few instructions and keep tweaking it until it works. To me, it's more efficient to debug in that manner since I am interacting with the code itself and the registers and everything (emulated, nonetheless) until I get it right and then I can compile it and rest assured that it will work.

People are talking about adding layers onto the assembler and slowing it down. This interpreter is not to execute the program in the end. It's only to make debugging more interactive becuase a debugger won't allow you to change the source code and constants and add lines of code and remove lines of code while it's still executing and to see the state of all the variables themselves since a debugger doesn't know what the variables are, just locations of memory.

This is a tool. Nothing more. How well it'll emulate the x86 architecture remains to be seen. At the least, it'll allow you to fine tune some algorithms while the program is still running and will allow you to see all the variable, modify the values of the variables, add/remove lines of code, change lines of code, and other stuff without having to keep recompiling and watching through a debugger showing the compiled result, instead, this shows you your actual source code.

People may not like it. Fine. But I'll tell you, tools like this make it much easier to debug because it's real-time, interactive, and based on the actual source which means you can interact with the variables and structures and such themselves, which most debuggers won't do, since they don't know they variable names and so on. In the end, the program will be compiled with MASM like it is today. The interpreter is just a different kind of debugging tool.

Just my $.02
Shawn
Posted on 2001-10-06 14:05:00 by _Shawn
You guys seen the VC debugger. It allows me to change the source while debugging and i can even change all the values in the variables. It seems almost like an interpreter to me.
Posted on 2001-10-07 00:38:53 by MovingFulcrum
An assembly interpreter for 16 bit code already exists,
and works very well (see my home page, follow the
link from 'A Ketman Page' to the creator's home
page). It does indeed make working out ideas and
algorithms much easier.

Don't let sceptics get you down, guys. Fact is, I have
felt horribly restricted ever since I moved from
learning 16-bit assembly on the Ketman assembly
interpreter to 32-bit assembly with MASM. The
interpreter let me single step, observe effects in
register windows, custom data windows, etc., then
either make changes to the code, back step and
run again, or make changes to some block of memory
and run another few lines, or whatever I cared to
do.

So go for it. I will certainly try it if you get it done;
I MISS my back-stepping, dang it! Oh, and the
16-bit interpreter isn't a simulation; it actually runs
the machine code created by your assembly directly
on the processor, retrieving resulting states and displaying them.

craig
Posted on 2001-10-07 02:08:59 by bitnaut
Falcrum,

The VC++ debugger doesn't run you're MASM source, tho, does it? Yeah, it'll debug anything. But will it integrate with the source of your MASM project? Maybe there is a way, but it's not an interpreter. When it compiles the project, it leaves lots of NOP's so you can make changes but there are points where you simply can't make changes without having to stop the debugger. Therefore, this idea is still superior.

I'm not preaching to you guys, anyway. If you don't want to use it, fine. You don't have to. But there are some who are at least willing to consider what it does. I think by having the word "Interpreter" it's giving the wrong message. It's a "live, interactive debugger that emulates the source code and lets you change, add, or remove source code during runtime". Once you've worked out certain things in real-time you can compile in MASM like you do today.

Thanks,
_Shawn
Posted on 2001-10-07 12:45:10 by _Shawn
If your implying it would act sorta like a resource editor would, where you can "see" and test menus, dialog boxes etc, before you compile it into your exe... this would be a most impressive tool in an assembly sense. (providing the overhead is efficient).

But i have to admitt that something like that for assembly in general would be VERY difficult, as a resource editor has certain boundries, but assembly in general can go practially anywhere with its code...

NaN
Posted on 2001-10-07 15:03:52 by NaN
Will it be coded in asm? What processors will it support? Will it be easy to add new processors? How will you represent the machine description? Could this serve as a translator as well?

It is a big project. I like the idea very much. :)
Posted on 2001-10-08 00:41:39 by bitRAKE
Generation 1 is a little simple. We are planning on just making it read an instruction or macro command, and emulating it's use. NOt really a .286 or .386p or .586 thingy, really. Read an intruction, execute. Generation 2 may be a little more complex. We've got our work. It appears to be easier to emulate C++ but this is fun :d


_Shawn
Posted on 2001-10-08 02:17:54 by _Shawn
Shawn,
I am all for the intrepreter project. I know vc debugger cant handle masm source. All i wanted to say was that even if u make something like it, it would be excellent :alright:
Posted on 2001-10-08 03:19:51 by MovingFulcrum
My parts of it will be written as asm DLLs. Should they prove useful & timely to Shawn then he may use them. Of course, one test of the usefulness of the interpreter is try & use it to rewrite itself, even the asm parts. It's a strategy as old as Lisp.
Posted on 2001-10-08 10:18:37 by rafe
Yes, rafe is writing the parser, scanner, and lexer... I'll be doing the actual interpretation part in C++. I have intentions to optimize it but to first get it working.

I have a plaging question I'd like to ask of people in this group. One thing that we'll have to do it give it the ability to perform API's and to read into .obj files, in the case you're including someone's asm lib or something... how would we go about reading an obj file and then executing a function? In most cases, it would already exist in a dll. For example, if my project that I'm going to interpret for debugging purposes includes the masm32 lib then how would we go about that?

Would we use the included .inc and then use that for type checking and so on, but then just loadfunction into the proc address in the dll? What about the variables that need to be accesses, that could be a tough one. I know it can be done, Borland and MS do it, so can we.

The other tough part will be to make the resource files run in the interpreter but that shouldn't be too difficult.

I think this can be done once we figure out how to get the flags and all that stuff working properly then the rest "falls into place".

For interpretation, we'll decode the instruction and then simulate it using all the internally simulated registers and flags and memory addresses and heaps and stacks and so on. There will be opimizations to make it not too slow. Of course, with it running through a emulation layer it won't be too fast, but then, since this isn't for normal program execution, that shouldn't matter. Once we have it working we'll clean it up and make it faster and better and more capable.

our ultimate intentions are to write an engine so that we can plug NASM, FASM, SPASM, MASM, TASM, HLA, or any other assembly syntax into it and it'll work. This means it has to be some kind of virtual machine but we're hoping to avoid that. But we'll see. We don't want to lock it down to MASM.

Thanks,
_Shawn
Posted on 2001-10-08 10:45:25 by _Shawn