Actually not really impressive, yet at least. Mostly I just changed the
locations for:
my $texdir="../doc/source/TG";
#my $asmdir="../avr8/words";
my $asmdir="../common/words";
so they pointed at the right place to be built. Then I yanked some old asm
files from release/5.1 to find out why the new ones were failing. Had I
tried the avr8 ones first I could have skipped that step. Pretty much from
that point I just put one file that worked and one that didn't next to each
other in common/words (the existing 2swap.asm and the old one of the same
name but with a "2" added to the end of the filename and inside the file).
Then I'd fire off make-refcard-rst and make htdocs from their respective
locations. Examine output, look up Perl term, lather rinse repeat. If I
manage to make some actual progress with the Perl file I'll post it here.
> I'm still fairly fluent in perl, so I expect this can be fixed
> to produce a refcard again. And yes I also expect to fix up the
> source .asm files. Regarding those headers: IFF the files were
> indeed generated from forth code, then I would like to include
> said forth code in the comment section, and add a line, how it
> was generated (I think this is a must for generated files
> anyhow).
>
This bit is what I was really looking for advice on. After playing around
with g4 a bit to find out how to include my own files in the hex build I
realized that the asm files in common/words and avr8/words look very
similar to g4's output. Maybe they were just generated from AmForth's
compiler? In any case, if they are end-of -he-road files and not something
repeatedly regenerated, fixing them to be compliant to whatever they should
be would be easy enough. The format that the avr8 ones use was what the
older versions had as well. That is to say, Three comment lines in order at
the top. Then whatever else will be added as far as comments go, finally
followed by the actual code. This is what I'm spelunking in the script for.
It most certainly needs to be much more robust. I'll almost certainly need
a hand to do multiple directories though.
So the takeaway would be to define a format of the first 3 lines having to
be how they are, or some other way to tag the stack--effect, category,
description and processor flavor. The first way is easier and the first 3
lines could just be jammed into what is now this clever, but touchy setup.
$prevline3 = $prevline2;
> $prevline2 = $prevline1;
> $prevline1 = $line;
That is why everything is broken. It almost seems if the idea was to be
able to have the 4 lines of comment, comment, comment, VE_NAME: be able to
be placed anywhere. Almost everything in the readASM subroutine keys off of
those. The only thing that does any other work is finding the actual name
from the .db "name",0 line, making sure everything closes, then shoving the
whole mess into a hash to be dealt with. At least I think that is what is
going on.
The decision to make is what should the header of the asm file have in it
and make them all conform. Like I said, I'll keep at it this week and post
here if I have anything helpful to add. As far as putting all the Forth
code in comments of the asm file, I don't know. Wouldn't it be better to
just have a forth source file somewhere in the tree? The asm files are nice
and tight and easy to read. If there is a bunch of extra info in there it
could make it messier to look through. I'm thinking more like when you have
a .c file and an .o file next to each other. They don't hurt each other but
since one can be generated from the other it would be easy enough to
automate the whole thing if there was a newer assembler and you wanted to
regenerate all of the asm files. Come to think of it, I guess that is where
the windows exe comes in to play.
In any case, define the header for the asm and I'll help out wherever (or
whenever) I can and have the time.
Mark
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
