Coldfire AGAIN

[AJCopland]

HenryCase wrote:

Karlos wrote:
How do you take, say, 16 4KiB pages scattered across the 4G physical address space that an application requested and originally thought was one contiguous 64KiB lump of memory and tell it "here is where your data was" ?

By arranging it into a 64KiB lump before you give memory control back to the program.

Wow you can do that? (note: this is sarcasm)
Ok technically it might be possible to go an find all of those fragments of memory allocated to a process using the MMU somehow but even once you've found them and "give them back" the addresses that you "give back" to the program when you congeal that memory aren't going to be the same ones as it originally had when they were allocated under the MMU scheme.

Karlos wrote:
A single allocation of memory on a VM system using an MMU that an application uses a single pointer to refer to can translate into many unrelated chunks of genuine physical memory. You can't assume contiguous address mapped memory is contiguous in physical RAM.

Give me an example of when you'd use a pointer to address more than one memory location so I can explain how its done.

Striding through an array :-D

With all due respect Henry both bloodline and karlos are trying to explain how MMUs work from a position of knowing, at least from a code point-of-view, how they function. So some of your replies have read as being rather rude.

Andy

[AJCopland]

HenryCase wrote:
My challenge is this. I have a program running which has got an important string "ABCDEF" stored in memory at real location "0x001" and virtual location "0x0FF". Using your knowledge of the Amiga's API architecture, I want you to try and corrupt this data. I am confident that whatever you suggest can be dealt with without breaking AmigaOS compatibility, so try and prove me wrong.

10: program#1 has address 0x0FF
20: tells program#2 that the string it wants is at 0x0FF
30: program#2 accesses 0x0FF and catches a waiter whacking off into program#1's soup...

...they never eat at that restaurant again :crazy:

[AJCopland]

HenryCase wrote:

AJCopland wrote:
Wow you can do that? (note: this is sarcasm)

Think of it like HD defragmentation if it helps you understand it.

Oh I understand what you're saying perfectly clearly. An old version of an arcade game conversion that I worked on used a shared pool of memory instead of doing full blown networking (don't 'cos I can't tell you which). Each machine was given a physical ID (using jumpers) and this told them what address they were allowed to write into, and conversely what addresses other machines on the "network" would be writing into.

This situation is similar to the AmigaOS how? You ask. Well with AOS you've got a linear address space. Which means that to program#1 a pointer with the address 0x0000FEED is the same as program#2s address of 0x0000FEED.

Now at this point my knowledge of workbench/AOS gets wonky 'cos i've never done any coding in it.

The above means that programs could, and probably did, pass around the pointer addresses to data rather than actual data itself because since nothing ever set or respected the memory protection flags it was more efficient to pass a 4byte memory address than a larger data structure like a string.

Implementing memory protection or memory management et al at this stage would break all of those existing programs, and probably workbench as well because they'd no longer be able to communicate with either the underlying OS or the other programs like they used too as each program would be within its own 4GB protected memory space and so the pointer addresses that it was merrily passing around would no longer match those of the program on the recieving end.

EDIT: The relevence to the first paragraph i wrote is that if those arcade machines OS had memory protection then they'd never get each others messages because whilst they'd all be accessing their _own_ versions of the correct memory addresses the physical section of memory that they'd be writing too would be different from the physical address that the other machines were reading from :EDIT

Now that might all be bollox because i've had a long day.

I also just realised that this was the ColdFIRE thread and I only came in here in the hope that someone would be commenting on THAT topic. So I apologise profusely to everyone for continuing this off-topic subject.

Andy

[AJCopland]

bloodline wrote:
Task A Stores "ABCDEF" at 0x0FF.
Task A sends a message to Task B.
The message simply contains 0x0FF.
Task B looks at Address 0x0FF and it doesn't find "ABCDEF".

Reason:
0x0FF are two different Physical memory locations to the separate tasks. infact Task B might even have some code at its 0x0FF, or anthing!!!

thats what i said ... ok so I was more uncouth :-D

[AJCopland]

HenryCase wrote:
Task A requests to store "ABCDEF", the MAU stores it at location 0x0001 and passes back a pointer to that location through assigning a 'virtual memory space' 0x0FF.
Task A sends a message through the MAU to Task B to look at memory space 0x0FF.
Task B makes the request to look at address 0x0FF, the MAU does not see a reason to not show this information, and fetches the string "ABCDEF" to pass on to Task B.

The reason that won't work is that there are no "requests to look at address 0x0FF" it simply does it. Theres nowhere for you to "insert" a virtual->physical memory lookup.

On systems with an MMU the hardware itself does the work of changing the address but it does this in the programs _own_ virtual memory space. Which is what brings us back to the original problem that Bloodline and I have pointed out to you, i.e. that virtual memory is _private_ to that program/task/etc.

If your MMU just let everyone read and write into the same memory space then it wouldn't be much use as an MMU because you'd still have the same linear address space that we have NOW on the AmigaOS and so you'd have no memory protection!

Your description would give things virtual memory, but it would give everyone the same virtual memory and thus it wouldn't give anything that ran in that virtual memory any memory protection.

Nice try but the system you've described doesn't fix any existing programs.
The only solution to this is to run the older Apps in a sandbox as someone else suggested and NEW apps can be run in a system friendly way using the MMU to gain memory protection.

The trouble is that this requires a rewrite of AmigaOS because AmigaOS itself is one of the main offenders for doing this kind of direct manipulation.

I suggest that if you want to continue this discussion we start a new thread.

Someone actually had an interesting topic going on here about the ColdFire and I was getting the impression that new versions V4e and V5 of the cores might actually have the necessary supervisor stacks to run 680x0 code using the cf68klib.

@FrenchShark
That asm listing you dumped earlier on, what version of the CF core was it for that made it necessary for you to emulate the entire instruction set?

Andy

[AJCopland]

biggun wrote:

Someone actually had an interesting topic going on here about the ColdFire and I was getting the impression that new versions V4e and V5 of the cores might actually have the necessary supervisor stacks to run 680x0 code using the cf68klib.

Yes, this is true.

Have you got your developer board yet so that this could be tested in some way? I'm not initially interested in the performance merely in the compatibility of the actual V4e/V5 cores. Speed can come later for me, I doubt that at 266MHz it'll be much slower than an 040/40.

For speed, for the games that won't run or are just unplayable then I'd be willing to learn ColdFire/68k asm again just to contribute WHDLoad based fixes! :-D
(I can already do some MIPS and x86 but it's been almost 15 years since I did any serious 68k! :-o )

@FrenchShark
That asm listing you dumped earlier on, what version of the CF core was it for that made it necessary for you to emulate the entire instruction set?

FrenchShark, post looked very interesting.
I would like to know if he is interested in working together in this project?

Yeah I'm curious about what the listing was for if the core is now meant to be so close to being compatible.
I hasten to add that I'm not saying it isn't necessary I'm just wondering what it is that makes full emulation of the 68k necessary on the coldfire.

Andy

[AJCopland]

Since we were originally talking about ColdFire and I don't care about MMU :-D I was wondering why no-one ever seems to mention the Turbo-CF (Yahoo group for it)?

It has downloadable designs etc though I don't believe it's ever been built.

I think I once read a thread about it but it was discounted becuase of the usual "ColdFire can't execute 68k code" blahblahblah. Since people on here are saying that they can I'd like to know what other things are wrong with the Turbo-CF design and whether it'd be worth trying to build one from the schematics?

If it IS a totally worthless design then could someone explain why?

Andy

EDIT: corrected _some_ of my appalling grammar :lol:

[AJCopland]

*bump*

anyone?

[AJCopland]

minator wrote:
However here's a question for you.
The Amiga, when it was launched was ahead in both software and hardware.
If the aim of Natami's is to bring the Amiga up to date why is it being thought of in terms of hardware only?

It makes sense to do a a first revision as an Amiga clone for 3.x, but going forward do you really intend to stick with OS3.x?

How about: because one is possible the other is adding memory protection retroactively whilst maintaining full compatibility :-D

Also it was me that's been pushing to get this ColdFire thread onto er... well talking about ColdFire crazily enough. Which was why the other thread was started by bloodline over in "Memory Protection AGAIN".

Andy