On Mon, 2008-06-02 at 02:09 -0400, Gene Heskett wrote: > On Monday 02 June 2008, Cameron Simpson wrote: > >On 02Jun2008 00:57, Gene Heskett <gene.heskett@xxxxxxxxxxx> wrote: > >| On Sunday 01 June 2008, Cameron Simpson wrote: > >| >And it seems I typed "L1BAE" and you typed "L1A8E". Sorry, that will > >| >have wasted your time. Corrected in the examples below. > >| > >| Mochs Nichs, it worked, and about 450-500 bytes of junk code has now been > >| removed from a 6k relocatable object. The original coder from 25 years > >| ago was either fighting with a broken assembler, or somehow used the z-80 > >| as a model for 6809 code, there was z-80 coding style trash all over it, > > > >Hey, I _liked_ the Z80! How many other machines have an LDIR > >instruction? Admittedly, the Z80 implemented that rather tackily > >inside... > > > >What constitues "z-80 coding style trash", btw? > > > Jump tables scattered around in your code, taking up valuable space cuz the > darned thing doesn't have a conditional long branch ability, just for starters. > Restricting your conditional branches to about 126 bytes either way from the > current pc makes for in-elegant, messy code. If where you want to go with a > conditional is 40k away, you have to hide the long branch on that same page > someplace. Smart assemblers & linkers might be able to hide that from the > coder I suppose, but when I was carving z-80 code in 1981-2, it was with a hex > monitor only. Nobody was giving away assemblers back then. Oh, and it doesn't > do pcr addressing either. Once I got used to that, I don't think I could ever > go back to totally fixed addressing. There be dragons. > > >| and strings of > >| code 10 to 40 bytes long that had an rts or a bra to someplace else above > >| them with no label, meaning it will never be executed, so why is it there? > > > >Leakage? How smart is this disassembler? Are there any jump tables? > > Were, I just took them all out cuz this cpu can do conditional long branches and > subroutine calls & returns. > > >Maybe it's "I'm changing the way I'm doing this but want the old code > >handy for later just in case". Even today I have a bit of python code > >I'm hacking on that has a bit of this: > > > > if True: > > do things the cool new way > > else: > > the old clunkiness, kept around because I wanted to remember how it > > was done > > > >Hard to say how much hard-to-remember stuff can be packed into 10 bytes > >of machine code though... > > Sometimes a lot, particularly if its a 6x09. > > >| I can > >| only guess 25 years after the fact. > >| Having programed in assembly or even just a hex monitor on the RCA-1802, > >| the z-80, and the motorola 6809 which hitachi turned into a much smarter > >| 6309, the 1802 is ok but different, the 6809's are 1.5 star genius's, the > >| 6309 is a 2 star, and z-80 I can only describe as drain bamaged. > > > >I didn't do a lot of 6809 and have never used a 6309. > > They will spoil you, guaranteed. > > >| >I see someone else has suggested: > >| > :g/L1A8E/s//isspace/g > >| > > >| >which in this case is semanticly equivalent but internally different. > >| > >| And that syntax is what I used for the last 4 hours. I'm not done by a > >| long shot, but this sure helps. If I can get it to build and run exactly > >| as before, but without all this guys trash, a printout will be a lot more > >| useful in terms of deciphering what its doing. > > > >You may want to turn this into a sed script then, if the label names are > >reliable (I guess from the same disassembly run they will be). On the > >other hand I don't see that a sed script will be any better than just > >progressively editing your listing anyway, as I presume you are doing. > > Correct, as I figure out what its doing. Its a fairly complex program in that > it can analyze the file structure of a disk to see what bits in the disks > allocation map should be set to indicate that cluster of sectors is occupied, > and spit out any warnings or errors, such as file but not mapped and mapped but > no file accounts for that particular bit in the map. The problems with it have > reared their head because it apparently does not properly honor the value read > from the disks LSN0 containing the data integer DD.BIT, which we are required > to raise in powers of 2 once the total disk size exceeds 131 megabytes. So we > need to fix it as some of the users of this machine are now running > multi-gigabyte drives. I have half of a 1GB set for this os, and the other 500 > megs is used by a virtual drive setup, so I can effectively have 255 35 track > single sided disks with basic programs on them instantly available. > > Yes, in some locales, the TRS-80 Color Computer 3 still lives. It runs a > mini-unix called OS-9, multi-user/multi-tasking. But that I expect is a bit OT > for this list. :) > > Thanks again Cameron, I appreciate the help. Too bad the man pages for vim have > been gutted. Next time I get near Borders I'll check and see if Tim has a book > on vim. > Assembly language was a while ago for me, but as I recall, the Z80's relative jumps were one or two cycles quicker than the long jump (no address to retrieve), so many coders used the relative jumps to optimize code for speed. Often unnecessarily. Jump tables were generally utilized to speed up decoding a passed register, so that instead of a series of decrement and jumps, the base of the table could be loaded, the argument doubled and added (16 bit addresses), and a mov PC,(hl) would accomplish the task. It seems to me that this was about 35 cycles total, which make it faster for calls with more than 3 frequently called routines. What one person calls messy is good coding to another. Jump tables were used in almost all assembly code that I remember seeing where any good amount of optimization was required, and that was pretty much processor independent. I liked the Z80, although some of the non Zilog implementations would frequently disturb the top of the stack often. I have also hated reading the assembly code for any processor where people kept old and useless code in the program. If it no longer did the job, why keep it in a running executable. If you wished to keep it for historical purposes, archive the butchered copy, clean up the release code, and add a comment why it was changed and the name of the butchered file for reference. Add documentation to the butchered file detailing why it was changed and what drove the changes, so that the future engineer who might be tempted to look would have good information. But from my experience, who ever has time to look at butchered code, or as in your case now, clean the mess up? It is tough enough to get clean code working and delivered. JMHO. Regards, Les H -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
