From: Richard E. <ed...@id...> - 2005-06-27 20:34:09
|
There are some specific features of this particular family that enable code execution from the MOVX RAM, specifically, allowing it to occupy either code or data space. My interest in it is limited, but for little more than academic reasons, I'm interested in exploiting the feature that it (the 89C420) can be induced to run code at 50 MHz from the RAM, but not quite at that speed from the flash. Several years ago, when I first took an interest in these ultra-high-speed devices, I was interested because the spec indicated the parts would operate at that (50 MHz) rate. When the parts became real, i.e. when production was upon us, it turned out that the FLASH read process wouldn't operate at that speed, so the mfg lowered the spec to 33 MHz, which works fine. However, it is, at least in theory, still possible to put some code in that MOVX RAM, which would then enable one to execute it a 50 MHz. I'm not sure there are many applications for this, but, as soon as I declare there are none, someone will surely produce it. I can imagine a digital filter or some such that would benefit, say, from operating under normal conditions at 24 MHz and then, prior to entering the code in the MOVX RAM, change the oscillator multiplier from 2x to 4x and execute that code at 48 MHz. Something like that might come up sometime. Now, there's due to be new silicon out next month. There's no telling, so far, whether that will still support this characteristic. There are other interesting features, involving external memory interface operation, that have me captivated as well. If you're not "up to speed" on these, they fall under the heading of "page" modes, of which there are two. In one case, by setting some internal SFR parameters, rather than multiplexing the low address byte and the current data byte on P0, they mux both bytes of the address on P2 and hold data static on P0. This can help with setup and hold times on data when running at ultra-high speed (remember, their instruction cycle is only one clock tick long, in most cases). In the other page mode, data and the high address byte are muxed on P2, while the low address byte remains static on P0. That can help with decoding tree propagation delays. Because the CPU core is aware of the next and last address, it knows when it can skip the mux cycle, as the upper byte (page address) doesn't change, so it skips that step. The result is that external memory accesses that might take two clock ticks in the "usual" mode, take only one. When this feature set is combined with the single-clock-cycle execution of the MCU, it turns out to be very fast, indeed. You've also mentioned the data-pointer-specific operations such as auto-increment and -decrement which might be highly interesting as performance enhancements. However, if it's easy enough to use inline assembler, those can be implemented as such. regards, RE Denver, CO ----- Original Message ----- From: "Dave McGuire" <mc...@ne...> To: <sdc...@li...> Sent: Monday, June 27, 2005 11:25 AM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > Richard Erlacher wrote: >> This gives rise to yet another question, however, and that's, "How can I >> persuade the software to execute code in the 1 KB MOVX RAM? Is there >> some trick to this? Can it be done with a call or other control transfer >> without discrete "fiddling" with CPU resources?" > > mcs51 is a Harvard architecture, with separate code and data memories. > Unless the Maxim/Dallas parts do something very strange (and > architecturally incompatible with mcs51), this won't be possible. > > -Dave > > -- > Dave McGuire > Cape Coral, FL > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |