[Coco] disk files and program speed

[Wayne Campbell]

Hi Mark,

It matters if you want your source code back now because you are still developing the procedures. It matters if you know the output is similar in look to the output of disasm, and you're going to be spending alot of time renaming all those variable references and re-establishing links.

But now? decode has displays so I can follow the process in it's execution without having to rely on a debugger I can't use if the procedure has to be packed and run from the command line. It also counts even the unnecessary things that occur in the I-Code, just so I can see how many differences there can be between one procedure and another.

I am working on the code in TextPad as it runs in MESS/NitrOS9. I sometimes have to wait almost an hour to test run the next changes because I found them as the decode was in progress. I need fast sorts and fast searches to get me through the process in a reasonable amount of time. I don't just break out of the process just because I found 1 small thing. During the course of one run I may find 3 or 4 different things that could or should be done differently.

Once the process works from beginning to end without error on the four procedures I'm using for testing, I will consider it ready for assimilation into unpack. All display code will be separated from the work-code, and all unnecessary counters and other code removed. The final result, I hope, is a utility that runs like disasm, but is designed for decoding I-Code.

That was the original intent behind DCom, and remains at the foundation of the project. There is more to DCom than just unpack. DCom was also intended to be a working environment, capable of allowing you to manipulate your code more easily. You would be able to rename variables. This would be handy when changing reference names like "S0014" to "proc". If you misnamed a variable in your original code, you will find it here. You can re-associate that variable to the one it was supposed to be. So, R0023 is really I0022. You can reassociate it and it will become another reference to I0022.

You can renumber your line references, and specify the block level. If you like organizing your code and using line reference numbers to establish "boundaries" between groups (like I do), you'll be able to make that happen easily with DCom. It's renumber function allows you to specify which numbers begin new groupings, what numbers to give those groups as a base, and then incrementing all line refs in that group by a specified amount for that group.


Record variables will be linked with the field variable references that go with them. This will make it easier to find occurrences of a given field and/or its parent record variable.

There were other things slated for future addition that never happened with the original DCom. And I have also gained a few new features to add, thanks to Ron Bihler. He was able to provide me with feedback on things he wants to be able to do with DCom, and I agree. So, in addition to everything else I have planned for DCom, there will also be

* identifies all called I-Code subroutine procedures
* associates parameter variables between calling and called procedures

I want to go even farther. I want to find a way to give the user a screen editor that will allow them to scroll through their code, select words or expressions, copy/cut and paste, syntax checker, variable and line reference checker.

And finally, I want to be able to have Basic09 running in a window that I can call from DCom, pass the source code to (using Basic09's load command and redirecting input), and run while you are still in the DCom environment.

And that's just what I want to do using Basic09 as the programming language. I hope to someday understand OS-9 assembler enough to be able re-write DCom in assembler, and once done with that, start working to modify Basic09 and increase its functionality. The truth is, Basic09 can do now what I'm trying to do with DCom/unpack/decode. All it needs is the ability to save the variables and line refs and other tables it creates from your source statements, save the source-level pointer list, and after packing save the i-code level pointer list that links the source-level offsets to the packed-level offsets. That, and a switch. A command from the command line that says

Ready
B:unpack myProc

Well, that's all future. I'm still working on correctly decoding the I-Code. While I already know what to do, writing the code to do it takes longer to accomplish. The faster search and sort algorithms are helping. I am seeing more acceptable decoe and sort times now. The literals are removed, and I will work on that code later. For now, I need to get back to decoding I-Code. Well, as soon as I get the error that creeped into the sort algorithm corrected.

Wayne




________________________________
From: Mark McDougall <msmcdoug at iinet.net.au>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Wed, November 25, 2009 2:33:35 PM
Subject: Re: [Coco] disk files and program speed

Mark McDougall wrote:

> Stupid question: if you have a 512KB/2MB machine, why not run a RAM disk?

2nd stupid question: this is a de-compiler, right? So how often are you going to need to run this process? Does it matter if it takes 2 hours?

Regards,

-- |              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco