Re: [Simulavr-devel] fab feature deprecated

[Michael Hennebry]

On Fri, 28 Feb 2014, Onno Kortmann wrote:

> On 02/28/2014 06:03 PM, Michael Hennebry wrote:

> > I'd thought this was already clear:
> > I was not attacking Onno's suggested code and data organization.
> > I was attacking the notion that the decision to be made is just about
> > taste.
> > The notion had it coming.
> I guess I should have been more explicit: The pros/cons are technical,
> but weighting them is taste.
> What do you mean by 'how many places' and 'how much clutter'?

By 'how many places',
I mean how many places a datum would have to be retyped if it changed.
If desired, clutter can be measured in characters, tokens or something else.
The harder part might be to define clutter.
One person's clutter might be another's syntactic sugar.

> These are the pros I see for configuration data as C++:
>
> - Simulavr is more self-contained, does not need configuration files
> - no parser needed for text files, so less generic code

To me, that is a non-issue.
There is no reason configuration files cannot come with the simulavr package.
It already has scripts.
My expectation is that the total amount of code would
go down and leave fewer nesting places for bugs.

> vs. a standalone config file:
>
> - easier to fix and change, no recompilation necessary
> - less boiler plate code, as needed for C++ vs. a part-config mini-language
> - part configuration and to an extent how much certain I/O features are
> supported can be figured out from the configuration file. For example
> when installing just a binary from a .deb.

I suspect that Python or awk would be able to chew configuration
data into a form readily digestible by the C++ code.
The syntax of the configuration data is important.
Duplicating all the timer data for atmega48s,
'88s, '168s and 328s would be a bad thing.

> Are there any other issues? What do people think?

Speed.
Generic bit-twiddling code is likely to be a lot slower
than bit-twiddling done with compiled-in constants.
If the difference is significant, I see two possible work-arounds.
Feed the configuration files to the build process.
They can be used to generate C++ files.
Allow configurations to point at pre-fabricated objects,
not necessarily entire CPUs.


BTW I like the GNU guys definition of source:
"the prefered form for making changes".

--
Michael   address@hidden
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then."   --   John Woods