Nueron / NuOS (ColdFire based project)

[Karlos]

Looks cool :-D

This guy and Oli HD should get in touch!

[bloodline]

lempkee wrote:
neuron:its really good to see ya around ;=) , i for one always wonder what happens to the developers around..

anyway i do work part time on games , developing and yes its abit crap due to delays and stuff but really i cant say its a bad thing + its on amiga so heh we dont expect to be millionaires or anything.

btw i checked all the designs on the website of yours (neuos) looks quite impressive and i must say i am getting more and more interested, though ifit wont run aos ..well u know...once a fanatic

Would you have a problem with it if I was running AROS, and as such was able to run all you existing OS legal Amiga software?

Or does it HAVE to be AmigaOS for you?

[Crumpster]

@ Neuron

WOW!! It's looking good, very good!!

Have you done hardware design before or is this a 1st attempt kind of thing??

You should definately get in touch with Oli HD over at the Amiga Coldfire Project

Cheers,
Graham C

[DaNi]

WOW! is a great project! all new boards and OS`s are welcome =) but for compatibility, make your os compatible OS 3.9 (like the morphos for example) and if you can emulata aga, cool!!! jejeje

Very well work =)

PD: A coldifre for my CD32! =)

[Oli_hd]

Hi,

I've known about the project for some time now (I joined the news group on the 27th May 2002) and did e-mail him a while ago about the V4 and compiling the 68K module with his software, what interests me is the Amiga Coldfire assembler software however it would be great if he did get a full motherboard out. (It would give a better chance of making the Coldfire route the most popular)
The boards looks very very professional and lots of very cool features.. and the dual V4 220Mhz version must be so fast.

I wish Stephen all the best and am keeping an eye on the OS, specially if it supports multi CPU environments.

PS: http://groups.yahoo.com/group/geckocomputerproject/

Oliver Hannaford-Day

[Framiga]

Hi nueron,

looking more closer your project (pcb design-layout) make me think, how "ancient" are our boards . . .and i mean ALL our boards :-)

I wish all the best, for people like you (and Oliver too)

Ciao

[Karlos]

@ Coldfire experts...

If I am not mistaken, the coldfire processor misses some instructions / addressing modes that impact on 680x0 compatibility.

I understand that motorola have a code base for 'emulating' the missing functionaility that operates through a trapping mechanism, but I expect that heavy use of this could cripple performance.

What occured to me was the idea of using a JIT mechanism on a coldfire to emulate the 680x0. Before anybody suggests I am crazy, I literally mean to process the code and 'expand inline' anything that would need emulation on coldfire. For the most part, the emulation would not need to modify the original 680x0 code.

It transpires this idea isnt as stupid (or as new) as it might sound. HP already managed something similar with their PA-8000 Dynamo system which even manages to run PA-8000 code on the PA-8000 faster than running the same code natively (thanks to intelligent optimisation techniques).

I'm sure it would not be impossible to create a similar engine to allow 680x0 code to run on the coldfire without relying on trapping unimplemented code every time...

[MarkTime]

Did you ever see that show "Galaxy Quest" and the woman goes: my job is to repeat what the computer says.

That's so funny.

Anyway, the reason you get a positive response, is because its impolite to say negative things.

Now, my job:

I would rather poke a fork in my eye than buy a 200mhz coldfire.  By modern standards its slow, dog slow.

[downix]

@karlos

95% of the changes from Coldfire to 68k would be invisible to applications, but on-target for the OS.  The Coldfire handles supervisor-mode differently, its memory systems slightly different, etc.

And the 5% difference is actually less than the difference in instructions between the 68030 and 68060.  

[Oli_hd]

Hi,

I would rather poke a fork in my eye than buy a 200mhz coldfire. By modern standards its slow, dog slow.

Yes but its a good speed for an Amiga and thats what counts, it  really depends what you want out of an Amiga, do you want a system to compete with PC's and Mac's, trying to be the number one platform again or do you just want a computer you like using and that does the job.

I personally doubt if Amiga will ever be number one again but I think its great fun to use and should continue to be developed but just not with Mhz and MIPS in mind but in how much fun and how easy it is to use.
If you want top Mhz go for a PC, if you want a real computer go for an Amiga  ;-)

PS: This is my personal view and may not reflect the views of the Amiga community or the world.  :-D

[Bobsonsirjonny]

MarkTime wrote:
Did you ever see that show "Galaxy Quest" and the woman goes: my job is to repeat what the computer says.

That's so funny.

Anyway, the reason you get a positive response, is because its impolite to say negative things.

Now, my job:

I would rather poke a fork in my eye than buy a 200mhz coldfire.  By modern standards its slow, dog slow.

Well - 200mhz is slow. But its a tablet PC - running a new OS, custom designed for it - all tied in one neat package - thus using overheads more efficiently, with little heat and power consumption.

 Its a great concept. While I dont see the point in an atx desktop system - this Tablet idea really does it for me. It would be perfect to take to say.. AUSTRALIA!!!

Its a good format - and really I do want one. When I go to Aus Im gonna take a digital camera - I wanna be able to back the images up - this tablet would be perfect for that.

[Karlos]

@downix

Really? I was under the impression that a fair few things were missing, such as scaled indexed addressing modes, word addition to address registers and so on. My understanding was that the software from motorola used a mechanism similar to that used by the 68040FPSP to emulate missing functionality.

In any event, to the nay sayers I'd say a coldfire powered amiga would kick bottom so nerr :-P

[downix]

@Karlos

Everything you've mentioned relates to how the OS works on the chip, not the software.  The software doesn't know nor care of the addressing modes available, it cares about getting data to or from an address and the OS handles that.

So, in short, AOS would need to be rewritten, but the software wouldn't for the most part.

[Karlos]

@Downix,

I'm not disagreeing with you - naturally the coldfire has its own supervisor architecture hence the OS would need extensive reworking.

The software doesn't know nor care of the addressing modes available, it cares about getting data to or from an address and the OS handles that.

Granted the physical address accessed is ultimately (thanks to MMU hardware) not necessarily the logical one generated by the application code, but I fail to see where the OS intervenes in for example

move.l (a0, d0.w*4), d1

or

add.w #2, a1

for instance. If, as I seem to recall (but may be wrong) these operations are not supported in the coldfire (along with others), some emulation mechanism must kick in to do the work.

Given I've seen plenty of d8(An, Xn*SCALE) modes in 020+ application code and add.w #, An in application code. If such operations have to be emulated by trapping or whatever, appication code using them will suffer.

Thats why I was thinking of some kind of JIT code translator that could for example convert

move.l (a0, d0.l*4), d1

into something like

movem d0/a0, -(a7)
lsl.l #2, d0
add.l d0, a0
move.l (a0), d1
movem (a7)+, d0/a0

on the fly and cache the cache the result (like any regular JIT). This has got to be way faster than invoking some kind of trap to emulate the missing address mode.

[nueron]

@karlos

I agree with you regarding JIT. I have thought about doing something along those lines.

ColdFire does support address register indirect with scaled index and 8-bit displacement.
The limits are that the index register only supports longword and that the scale can be
1, 2 or 4 (8 only supported if you have an FPU).

move.l   (a0,d0.w*4),d1 ....... illegal
add.w   #4,a1 ................. illegal

move.l   (a0,d0.l*4),d1 ....... ok


It took a little while for me to modify my assembler habits, but I'm used to it now. With
V4 they added byte and word extensions back to the cmp instruction and added a few more
such as:-
           
mov3q.l   #5,(100,a0,d0.l*4) .. move 5 longword extended to destination
............................. length of operand + extension = 32bits
               
mvs.b   (a0),d0 ............... move byte , sign extended to long
mvz.b   (a0),d0 ............... move byte , zero extended to
............................. mvs.w and mvz.w also supported

sats   d0 ..................... signed saturate, sets max/min(overflow)
intouch   (a0) ................ prefetch instructions  into cache


Motorola have even added some interesting ones to the V2 core (MCF5282):-


bitrev   d0 ................... bit reverse (31..0)<->(0..31)
byterev   d0 .................. byte reverse (endian modify)
ff1   d0 ...................... find first one in register
strldsr   #val ................ push sr to stack, then load new sr


Regards,
Stephen.

[Karlos]

@neuron

Unlike emulation of alien CPUs. such a 680x0->Coldfire JIT mechanism could be optimised in such a fashion as to leave big chunks of 680x0 code that is 100% coldfire compatible alone and avoid processing it.

However, when you consider HP's Dynamo it even begins to make sense to process it all. They get speed increases for code as a result of cacheing a linear sequence of instructions that represent a path through a complex set of conditions or a loop (its even more surprising when you consider dynamo is actually an interpreter 99% of the time and JIT converts hotspot areas only).

I've often wondered if such a JIT also makes sense on 68040/60 for running code that uses missing instructions emulated by the respective 680x0.library. Oxypatcher etc. is almost like this, but IIRC it patches the unimplemented instructions with a jump to code to emulate the instruction. Not as efficient as a genuine JIT, but much less work too. Its another alternative for running full 680x0 code on coldfire (maybe motorola's software does this ?).