[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