Re: [f-cpu] Yet Another Upload

[<cyrano@nerim.net>]

Maintaining a (very very big) simulation environnement was my job during the last 12 month. 

It's was a bunch of shell script, perl script, tcl script, some C programm, some use of bison, and m4...

The guys who create this mess add created a whole new tiny language to generate c .h header, .vhfl header, .mak for the makefile, .ld for a linker.

This languages has a very limited parser.

I find this completly supid and i don't understand why not simply parsing vhdl files to create .c files.

Parsing vhdl files are easy for simple things. But you always need more complicated things than register value: like memory size, bits fields, arythmétique in the assignement, etc...

After some disscussion, i think that the easiest way, should be to use perl and it's outstanding data structure. Then a fonction could be written by output.
ex:
%myvar = { reg1 -> {unsigned, 123, 
                    fields -> {bits1_3 -> "1-3"}}
 }

Michael Riepe <michael@stud.uni-hannover.de> a écrit :

> On Mon, Apr 21, 2003 at 04:18:32AM +0200, Yann Guidon wrote:
> [...]
> > >I'd really like to get rid of m4.
> > >
> > 
> > huh, really ? i find this very handy, though ....
> 
> M4 is probably one of the most powerful tools ever.  But it's only a
> text processor.
> 
> > >In particular, I don't like the fact
> > >that we have to run m4 every time we modify the configuration.
> > >
> > how often do you change the configuration ?
> 
> I did it once or twice when it still was a VHDL file.  And I have my
> own files for the C side (most notably fcpu_opcodes.h) that I change
> directly because (a) the m4 stuff wasn't complete at the time I wrote it,
> and (b) I didn't want to mess with it.
> 
> We will have to change it, however, when we start assigning opcodes
> (I only did a preliminary assignment in the fctools package).
> 
> > >I prefer to change the VHDL sources directly.  C headers can be generated
> from
> > >VHDL -- all we need is a procedure that takes all the definitions and
> > >prints them in C format.  Since VHDL has text i/o capabilities, that
> > >shouldn't be too hard to do.  (Note that it would also work the other
> > >way round -- edit C and generate VHDL -- but since VHDL is our primary
> > >source, I prefer to generate the C stuff.)  Of course we must distribute
> > >pre-built C headers, in case someone has no VHDL tools and wants to
> > >install only the software.  But that's not a problem either.
> > >  
> > >
> > 
> > i'm not very happy with this solution : it will obfuscate the sources 
> > too much !!!
> 
> Huh?  I think it makes it cleaner.  I guess only few people really
> understand m4 (mostly sendmail admins ;).
> 
> We already use two languages: C and VHDL.  Both of them can handle the
> conversion easily.  Adding a third language is overkill.
> 
> > First, not everybody will want to use it because it uses VHDL, and "SW 
> > people"
> > who simply want to run an emulator won't want to fiddle with it.
> 
> Therefore, they get pre-built C headers with the distribution.
> 
> > Second, with the M4 solution, the files are available in source form, 
> > very similar to the target form.
> > Using VHDL to generate the files will make the original form very very 
> > oscure, full
> > of
> >    write ("blahblagblah", somevariable, "blablah");
> > so i think that m4 is not a bad trade-off.
> 
> It's more like
> 
> 	print_c_define("name_of_variable", name_of_variable);
> 
> and similar.
> 
> > Of course, if you find a better solution, i'd be interested to see it :-)
> > like, huh, you want to reimplement m4 with VHDL ? :-P
> 
> Of course not.
> 
> [tools]
> > and what about GHDL ? :-) "it's free, too" :-P
> 
> I don't have an Ada compiler to build it.
> And I doubt that it is complete yet.
> 
> [...]
> > >VHDL code, manual and emulators are badly desynced.
> > >
> > obviously.
> > maybe because different persons do different things, right ?
> 
> Yep.  Therefore I suggest that the authors/maintainers of execution
> units also maintain the corresponding manual pages.
> 
> > >I'll take care of the emulators,
> > >and I think it would be wise to review the manual pages as well --
> > >at least those corresponding to the EUs I wrote myself.  I just need a
> > >copy of the current sources.
> > >  
> > >
> > i believe the latest versions are available easily from Cédric's site.
> 
> At seul.org?
> 
> > >>>Third, I'll have to update the assembler and the emulator.
> > >>>Finally, someone can update the machine description for gcc.
> > >>>
> > >>As you probably know, i have returned back to plain old electronics to
> get
> > >>some pocket money from time to time. Now, i have almost all tools to
> make
> > >>decent PCBs in small series at decent prices. When the first FC0s will 
> > >>come out of fundry, we'll be able to use nice development kits :-)
> > >>    
> > >>
> > >Will they run Linux? ;)
> > >  
> > >
> > except slashdotters, who really cares ? :-P
> 
> I do, and I *never* visit /. :-P
> 
> > frankly, i have recently started to master certain techniques and 
> > electronic technologies,
> > so if we ever get to the fundry, the outcome will be really interesting 
> > and the
> > PCBs will have interesting features...
> 
> Like...?
> 
> > >>But there is still too much work to be done on the SW side; so we'll 
> > >>have to "wait a bit" ...
> > >>    
> > >>
> > >Hmm... we have a gcc port, an assembler, a linker and two emulators.
> > >
> > do they all work together ? are they all correctly updated and maintained
> ?
> > are they easy to install and use ?....
> 
> Yes, yes, and yes.  The latest VHDL improvements aren't integrated yet,
> but they will be in the next fctools release.
> 
> I have installed fctools and fcpu-gcc on my system, and I can compile,
> assemble, link and run C programs with it.  There just is no libc yet,
> and system call support in the emulator is limited, but it's enough
> for a `hello, world' style program -- that is, enough to begin with.
> 
> I have already started to add better system call support; I'm going to
> finish it when I'm back in `C mode'.
> 
> > >That's all SW people need in the first place.  I'm currently
> concentrating
> > >on the HW side again -- since many people can do SW development but
> > >only few seem to be able to write VHDL code, I won't waste my time doing
> > >software development (of course I'll maintain my software, but VHDL has
> > >higher priority now).
> > >
> > i'll maybe come back to hardcore F-CPU dev in many months.
> > In the meantime, i am doing uC and DSP.
> 
> I guess it's necessary to earn some money now and then...
> 
> -- 
>  Michael "Tired" Riepe &amp;lang=fr">Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org
> with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/



___________________________________
Webmail Nerim, http://www.nerim.net/


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/