Re: [sim] new port: Renesas RL78

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 2225 bytes --]

On Wednesday 16 November 2011 14:36:20 DJ Delorie wrote:
> > > +	$(ENDLIST)
> > 
> > this $(ENDLIST) business looks like dead code ?
> 
> I've been brainwashed to end lists like this so that new lines always
> end with a continuation char, which - in ancient and possibly modern
> source control systems - prevents two independent additions from
> becoming dependent on each other.  It also allows you to sort or
> otherwise mess with the list, without worrying about which lines have
> continuation characters and which don't.

sounds like it should be a standard in the wider binutils/gdb/etc... tree, or 
should be omitted and forgotten about.  all these youngsters don't have a clue 
what "$(ENDLIST)" is for, and heaven forbid someone has ENDLIST exported in 
their env when running `make` ;).

> > > +int
> > > +main (int argc, char **argv)
> > > +{
> > > ...
> > > +  setbuf(stdout, NULL);
> > 
> > doesn't this hurt performance ?  especially when tracing ?
> 
> Very important when emulating the target serial port, though.  I
> suppose I could rework that logic, but so far I've mostly been worried
> about "runs correctly" and not "runs fast".

hmm, personally i've left that up to the host to run `stty` rather than 
mucking about with terminal settings on people.  although that covers input 
and not output.

for output, i have my uart simulator explicitly flush whenever it has data to 
right.  that way general things writing to stdout don't take a penalty, but 
the serial which wants bytes sent immediately still work.

> > > --- /dev/null	1 Jan 1970 00:00:00 -0000
> > > +++ sim/rl78/mem.c	16 Nov 2011 05:44:54 -0000
> > 
> > seems like much of the utility of this file is duplicating the core
> > mapping= s=20
> > logic in like common/sim-core.c :/
> 
> It's mostly about emulating memory-mapped hardware and the weird RL78
> mapping rules, though.  The common parts are a small part of it.

common/ provides frameworks for emulating memory mapped devices :).  the 
Blackfin port uses this heavily so that specific devices are cleanly managed in 
sep files.  see all the fun bfin/dv-* files.

although converting to that is probably non-trivial.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]