> > Ethan Dicks wrote: > Yes, but IMHO the BRK instruction is slow. Together with getting the > vector from the BRK address on the stack, then jumping to this address, > with saving registers along the way (during the vector get) etc. > This is _much_ slower than a simple jump table. Yes, it is. It's a design tradeoff. Keep in mind that we are talking about operations that are executed rarely, even only once per execution, like opening a file. How many times does an assembler open the source file during a compile? If it takes 400 cycles vs. 450 or 500 cycles, is the user going to notice? If blindingly fast operation is important, then no, that BRK mechanism is inappropriate. If the ability to port to similar, but not identical models of 6502 computers, then I still argue that it's a good way to go. This inherent slowness in software interrupts is why we were all stuck with the 8250 UART on PeeCees, BTW. There were BIOS calls for most I/O, but the applications bypassed the BIOS to bang the UART directly to get the maximum speed out of the port on a 4.77 (and 8.0) Mhz processors. With all these applications that depended on the register set of the serial ports, it was impossible to sell a serial card that didn't at least have a compatibility mode with the 8250. We had to wait until a working 16550 design his the streets (and software was updated to match) before speeds much above 9600 baud were common. No, I don't enjoy a 20 cycle delay on an I/O call, but unless you are loading data one byte at a time (serial I/O), it's an acceptable tradeoff. For a block of disk data, it's a trivial amount of delay, especially when you are talking about the IEC bus. For a single byte, though, each and every byte, it does add up. > <self-plug> And my relocatable file format easily allows 'late-binding', > i.e. relocation of jump tables for example at load time </self-plug> That is another way to go, if you have ROM support for another load format. "Back in the old days", we didn't have fancy a.out or ELF- style load files on 8 bitters. If we had, some things might have been easier, but they would certainly have been slower. My suggestion was borne out of my efforts to port a complex program from the C-64 to the PET. I spent weeks poring over a disassembly of the C-64 and PET ROMs to match up Kernel routines. I wrote Kernel stubs for the PET port and stuffed them below $0800, where the main body of the C-64 code never looked, anyway. I compiled the C-64 version with real C-64 Kernel addresses and the PET version with a combination of Kernel jump points (for those few that matched, like $FFD2) and my own jump table to my own Kernel stubs. It mostly works. The program is complex enough that it is stomping on some zero page location that is used by the PET 4.0 ROM routines for printing and I/O, but is unused on the C-64 by those same kernel support routines. If I ever get time to look into it, I'm considering encapsulating all the code in my source as a way to eliminate stray side-effects from the PET ROM code. If I had an easy way to emulate hardware breakpoints in VICE, I'd do it that way (i.e., jump to the monitor if the PC is between $XXXX and $YYYY and location $00ZZ gets written). For the record, the program I've ported is the Zork Implementation Program. I was able to get the source to compile and run on the VICE VIC-20 emulator (screen size), except for the status line being munged on the narrow screen. On the PET, Zork I plays, sort of, but Starcross does not. Strange characters appear on the screen in a very deterministic way; I just have no way to track what pointer is getting hosed. -ethan - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.