Stupid cache question.

Jim Stewart wrote in news:WPadnT1sL59mi snipped-for-privacy@omsoft.com:

Not me. I'm not sure how you could either without special instructions to load data into the D-Cache. Typically you can zero, touch, store (flush), or invalidate a cache line but not place data into a cache line. Some CPU have memory that can be configured as cache or RAM but that doesn't sound like your application.

This is how modern day Pentium based BIOSes work. They have the ability to turn cache into real RAM - sure beats trying to do memory sizing with no memory or stack!

-->Neil

There are processors (like the MPC8540) that hvae L2 cache that can optionally be configured as a block of SRAM.

On old Sun machines, even the boot monitor (with serial user interface) runs without RAM :-) (Hey, m68k has 15 32-bit user registers.. what do you need RAM for? :)

-jm

Tell us more, including how to do it.

That would get me in trouble with AMI.

-->Neil

I sure don't know how to do such a thing (explicitly use cache as RAM), but programming without using RAM at all is certainly possible. On the x86 platforms, for example, you can simulate subroutine calls by JMPing directly to the "subroutine" after storing the return address in a register, say EBX. Such a call would look something like this:

; simulated subroutine call lea ebx, over ; load effective address of "over" label jmp psuedosubr ; jmp to the pseudo-subroutine over: nop ; code continues

; simulated subroutine body ; obviously, there is no stack frame nop ; do stuff ; ... jmp [ebx] ; return from pseudo-subroutine

This avoids using RAM, but maintains some semblance of organization to the code. It's probably pretty obvious how you could wrap all of this into macros, and if we wanted to get really tricky, we might be able to use another register (or bit of another register) to tell us whether we're in psuedo-subroutine or real-subroutine mode and execute the correct return accordingly. I doubt that would be worth much, though, given any reasonable amount of ROM and RAM. The only purpose I know of for such code is running before the memory hardware is set up to be usable and/or if the requirement is to do RAM testing and diagnostics before using the RAM. I don't think there's much sense in actually building a completely RAM-less system.

Ed

I don't know if anyone did it deliberately but I recently bought a JTAG debugger for a CPU with a Flash Programming Option. The Flash module would download a small program to RAM, download a small chunk of data (I think it was 4-8k at a time) and then use the program to actually handle the Flash Algorithm for the block.

When I needed to change the Flash type I had to buy the source for their programming code so that I could keep the same interface registers and call address. It was then that I noticed that the code was originally written for a previous generation development board and that there was no RAM in the current hardware at the addresses used, but the Cache (16K) was saving them and the whole thing was working fine.

I could even trace it in the JTAG debugger (with totally screwed up timing) and it would work, but it I tried to display a large enough block of memory at another address the system would head off into the woods.

Stan Katz