[Coco] About the tylg (type language) ident report

Chris Hawks chawks at dls.net
Tue Oct 23 21:33:30 EDT 2012


On Tue, 23 Oct 2012 20:45:41 -0400
Gene Heskett <gheskett at wdtv.com> wrote:

> On Tuesday 23 October 2012 20:19:33 Robert Gault did opine:
> 
> > I've just realized that our current use of ident to report a 6809 vs
> > 6309 module is essentially useless for the NitrOS-9 project. The reason
> > for this is that the asm files used to build the project do not include
> > a variable for language. The result is that a module such as IOMAN
> > which can be built for both 6809 and 6309 systems will always give an
> > ident report as a 6809 module.
> > 
> > Does anyone care about this? It could be corrected but would require a
> > large amount of work on the NitrOS-9 project and the results could
> > still be confusing.
> > 
> > If a correction were to be made and I am not volunteering, each .asm in
> > the project would need to be checked for the presence of 6309 code and
> > when present the following added to the asm file.
> > 
> > 	ifne H6309
> > tylg	set	Systm+Obj6309
> > 	else
> > tylg	set	Systm+Objct
> > 	endif
> > 
> > You should not do this when 6309 code is not present or all programs in
> > a 6309 package would be labeled 6309 even if no such code were present.
> 
> I believe this is probably less of a problem than it could be, primarily 
> because the huge majority of the modules that go to make up the kernel do 
> not actually have any 6309 only code in them.  If that module builds on a 
> 6809 premise setting, without the above ifne verse, then it likely does not 
> actually have 6309 code in it.  Or this assembler (referring to the nitros9 
> assembler, not mamou) would be squawking about it.
> 
> So far, ioman and the level3 only nitro are the two modules needing fixing 
> that we have found.  I think that tells us that there are lots of the 
> kernels separated out calls that probably could be further optimized for 
> the 6309. The 'hot' paths however can IMO wait until we have stability 
> again.
> 
> This somewhat resembles the "if it not broken, don't fix it" method.  Fixes 
> here to make it conditionally build optimized for each cpu, are generally 
> of the .1% speedup variety except for certain bit shift situations where 
> the first 8 bits each way can be done in 3 or 4 instructions, about 20x 
> faster than the usual loop till done construct, and which none of the so-
> called optimizers we have know a thing about, so it will take many such 
> fixes to get another 2% worth of real throughput.

Gene:

	Just as a matter of interest:

'findg level\* \*.asm 6309 | grep -i .asm | wc -l' says that there are
92 .asm files with 6309 in them in the 3 levelX dirs.

 findg takes a directory to start in, filename_pattern, and grep_pattern
(find $1 -name "$2" -exec grep -lis "$3" {} \; -exec grep -isn "$3" {}
\; | more ;)

	When we have the time, it should be worth the effort.
-- 
Christopher R. Hawks
HAWKSoft
------------------------
I develop for Linux for a living, I used to develop for DOS.
Going from DOS to Linux is like trading a glider for an F117.
	-- Lawrence Foard, entropy at world.std.com



More information about the Coco mailing list