New version uploaded at http://home.earthlink.net/~hxa/

No new features, but (prodded by BDD) error reporting has been enhanced. So:



Now produces an error file that looks like this:



Having the assembler say exactly what it thinks is going on is a definite improvement. No more puzzling about "why did...?" until the light bulb comes on "Oh! because the assembler thought blah blah blah". Doesn't add anything in many cases, but does in enough to make it worthwhile.

When it comes to assemblers, diagnostics with appalling detail are definitely an advantage over a lack of detail. You can always filter out/ignore the former, but not the latter.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Error and warning reporting is important, but you can overdo it. For instance, FPGA toolchains spit out thousands of lines of warnings, some of them really important (like eliminating most of your circuit due to a misspelled identifier). I've never seen a project that does not generate warnings - most of the time it's normal behaviour. It's pretty much impossible to read the entire output, making it useless... Needle in a haystack.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Not on UNIX or Linux. Send the diagnostics to a file and use grep or similar to search for things. The C compiler often spits out a lot of diagnostics when a semi-colon is missing from the end of a statement. Redirecting STDERR to a file makes tracking down the error less difficult. I've been doing it literally for decades.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Well, maybe some of us enjoy grepping files for meaningful warnings, but others enjoy it less. My ideal scenario has less than a screenful of information, and important information at that, not copyright notices and things that should be ignored. As far as I am concerned, a message that comes up requires attention (and a fix, even if it kind of works as is) - or don't show it to me!.

EDIT - redirecting output to a file, while a wonderful feature, defeats the purpose of the warning system.

Any diagnostic chatter should not be seen unless requested.

Anyway, not trying to start a battle here - keep up the good work!

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Mmm, just have to wade in here on the whole topic of error reporting...



Yikes! A silent failure seems pretty darn useless. If the tool doesn't offer an option, it may still be possible to direct output to a null device, but why?

Peter Brown in "Writing Interactive Interpreters and Compilers" (highly recommended, even if it is >30 years old), points out that "the error case is the normal case" - by which he means that during program development, it's normal to run into errors. Once a program is completed, there should be no more errors. But when it's complete work on it stops. So the majority of time a programmer is creating a new program, errors are happening.

So what HXA tries to do is provide enough information to answer the question "why didn't what I expect to happen actually happen?" To the extent that it reduces the time necessary to figure that out, it is successful.

On sending error output to a file, I'm a big believer. Partly because one error can cause another, cascade error, which occurs only because the first did and not because it's a real error in itself. I want to be able to see the one that set off the cascade. Sometimes I see a way to prevent the cascade from happening.

But also because HXA has a lot - hundreds - of test programs, some suppposed to succeed and some designed to fail. Every so often I want to test all of them, to see if any changes I've made recently cause some test result to change as well. This has been very helpful in pointing out where I've created a test for some obscure possibility and then forgotten that it can happen - but the test is still there, waiting to remind me.

The point is I'm not about to wade through the output of hundreds of tests to see what happened. Instead I have a collection of batch files and AWK scripts that go through them, trying to match up what should have happened against what actually happened. The output of those programs is what I look at. If they say something changed, I have to fix either the source (oops!) or the test (the definition of "what ought to happen" changed).

It's not hard to create "filters" that scan through voluminous output picking out only the "important" stuff. It's almost exactly what AWK was designed for in the first place. Perl is probably a good pick for the job as well. By all means go ahead and ignore the unimportant stuff, but don't assume it's all unimportant.

I think I'm agreeing with you here, but:
The unix toolbox philosophy is to use stdout and stderr appropriately, and let the invocation do any necessary redirection. It's a courtesy to provide a "-q" switch for quiet mode, or a "-v" switch for verbose, or even a "-l" switch to write to a logfile.

It's also nice to be able to enable and disable warnings in the resulting code through directives. Ideally somewhat selectively, rather than "all warnings".