First of all what kind of ill designed database this is? Ok, don't answer. If that's your goal, I'd do it like any other operation, read the fields to compare in chunks of max say 64K (well in reality i'd use the block/cluster size of the drive) and compare it. Chances are pretty good that they will be already different in the first block, and disk access time is here more relevant than comparsion speed (which is done in one machine instruction, at the spped of the data bus). Even if your CPU is be able to handle megabyte size fields in one chunk, the incremental compare will outperform... As so often algorythm wins over brute force. Gruss H. (I did several 100k of 80186 assembly :) -- VCF Europa 4.0 am 03./04. Mai 2003 in Muenchen http://www.vcfe.org/

On Wed, 12 Feb 2003, Jeffrey Sharp wrote: I'd tend to guess that the 1MB fields probably come from the storage device holding the database... Unless you're assuming that the database is stored in someone's brain, and that they're toggling in those 1MB fields on the console switches. The original problem has the given of there being a database. I think we can safely assume that there's at least one "table" in the database, and that within this table there is more than one record--otherwise the excercise of sorting it would be rather silly--and that those records have at least one field of 1MB in size. The original problem implied there were more though, which would make the task more challenging. The other given is that you've a machine with 1MB of RAM. So... it very logically /follows/ that this database has to live somewhere, and it has to live somewhere that's not in RAM. Whether one assumes it's on a floppy disk, a hard disk, tape drive, paper tape, punch cards, or that it's being interactively toggled in via the console switches--the process being suggested for sorting it still holds, albeit with varying degrees of performance. Hans' assumption of it being disk I/O based is the most sensible of those options, but the general approach of his solution is valid with any of the other alternatives. And if you assume you don't have some sort of I/O channel for accessing this database, the problem most assuredly won't be with not having enough RAM! Actually, there are two other options: (1) the database is entirely in RAM, it has one table, with one record, with one field of precisely 1MB in size, or (2) the database has zero records. In either of those cases, you don't even need to write a sorting program since the tables are already sorted. -brian.

And thusly Hans Franke spake: So would the 65816 be included in this "list"? Cheers, Bryan

----- Original Message ----- From: "Eric Smith" <eric(a)brouhaha.com> To: <cctalk(a)classiccmp.org> Sent: Wednesday, February 12, 2003 1:57 PM Subject: Re: Virtual vs Physical memory (was Re: Designing around a 6502 ) :-) Good Answer This has been argued many times. Personally, I would go with the width of the accumulator(s), 8 bits for 6809, even though there are special (or perhaps BECAUSE they are special) instructions that use the combination of the two accumulators as one 16 bit ("D") register. Stuart Johnson

Roger Merchberger wrote: Having brought the subject up, I tend to think the 6809 is a 16 bit cpu because of the good addressing modes and the Intel 8086 a 8 bit cpu because of the lack of them. Also OS/9 for the 6809 was very nice system. Ben.

I always liked the 6809. I had a small FLEX system for a while that was fun. But sadly, Motorola managed to blow their own head off with the 6809, compared to the market share it could have had. "OK, 6809s are available this quarter. The 6809e will be next quarter. Oh yea, and three quarters out is the 68000." Only a small percentage of the market didn't wait. Especially after the 68000 as a microcode core was validated by GM buying up so much of the production. According to friend of mine that worked at IBM, the 6809 was a serious candidate for the what became the PC (remember that the original PC had a projected market-life of 1 year, and the IBM was getting out of that fad). What drove the the PC to use the 8088 was the fact that they had 10 Intel blueboxes sitting around from the DisplayWriter. Since the PC was to some extent a non-officially sanctioned project, they elected to use the tools on hand, rather than purchase Exorcisor development systems. The rest was history (and my friend has serial #0001 of the PC Jr, and the first 5MB HD. He also was the developer of the PC Jr. speech system. Another buddy was the lead architect on the VGA. Did you know that approximately 30% of the logic in the VGA was put there because it was on the CGA and no-one knew what it did? And management wanted the lowest compatibility risk path.) Somewhere, I even still have a small 6809e system I point-to-pointed on a piece of that gawd-awful Radio Shack phenolic board with the single side copper pads. I think it has a modified MikBug monitor on it. --John

Tony Duell wrote: I have not the foggest idea, but fancy calculator comes to mind because of the BCD math bit. Ben.

Tony writes: HP 9810 and 9820 perhaps? I haven't studied them in depth, though at some point I may need to do so in order to get my 9820 working.

[Charset iso-8859-1 unsupported, filtering to ASCII...] I tend to agree, but I would specialize that even further. As time goes on, I become more convinced that ALU width should be the determinant of bittedness. The 6809 requires multiple ALU passes for a 16 bit operation because the ALU is 8 bits wide. The 68000 is a 16 bit processor for the same reason. I seem to recall that that makes the 8080 a 4 bit CPU, though. Eric