Re: [Simulavr-devel] Multiple CPU - Architecture discussion

[Knut Schwichtenberg]

Jörg,

thanks for clarification.

Joerg Wunsch wrote:
> As Knut Schwichtenberg wrote:
> > -> Visual C vs. gcc
>
> It's not necessarily Visual C.  MinGW could be used as well.  It's a
> GCC compilation environment, but offers access to the native Win32 API
> rather than any kind of emulation (as Cygwin does).  I'm not even sure
> whether AVRDUDE can really be compiled in Visual C or not.

Here we come to a simulavrxx specific issue. simulavrxx is linked together with 
swig to become an extension to an interpreter language - currently TCL/python. I 
think it depends which compiler is used to create the interpreter. My experience 
with ActiveState perl on Windows was a "no go" for Cywin GCC. It starts with 
nmake Makefiles and ends with Windows specific paths which could not be handled 
by Cywins GCC.

> So for
> example, the ATmega64 and ATmega128 /look/ like two members of a
> family, but they actually aren't up to the deepest level of detail.
> One obvious difference between both that immediately springs to mind
> is that the BREAK instruction only works in the ATmega64 but not in
> the ATmega128 (so the latter cannot support software breakpoints in
> the JTAG ICE).
That would not bite us, because we are on a simulator :-). But I expect other 
things that could bite us :-)


> Not yet, at least not directly.  But it's the ultimate goal.

> So if
> you take it to the letter, you aren't even allowed to have these files
> on a non-Win32 machine unless that machine could execute the Win32
> installer...  (A plain basic Wine installation crashes when trying to
> run it.)
But installing it on a server disc... okay, I got the point - forget it. 
Partdescription file can be used to derive information - that's how to use them.

> This offers us an additional
> advantage: any information that's /not/ in the Atmel files but which
> we want to have in our headers (like, for example, old names of IO
> registers that have been renamed later, or the old avr-libc SIG_XXX
> style interrupt vector names) can be maintained separately.
But that means generate an intermediate file, extend it manually or merge it 
with a manual extension and use the new extended file for the final step. Sounds 
what we have to do...