Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: freqmax on May 01, 2009, 05:36:30 PM
-
Is there any features that the 68060 is missing that any programmer would love too see?, now that softcores are possible ;)
-
I'm under the impression that some instrutions in 68040 were removed on the 68060. I don't know which ones though.
-
Maybe the move16 instruction?
It is quite useful to do fast memory copy.
IIRC, the movep instruction was also removed from the 040 and 060.
Regards,
Frederic
-
Download MC68060UM.pdf (http://www.freescale.com/files/32bit/doc/ref_manual/MC68060UM.pdf?fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation)
Read the document, specifically appendix C (sections C.2 and C.3 in particular).
PS. move16 is not missing.
-
SIMD instructions?
vector processing instructions?
-
No.
-
SIMD instructions?
vector processing instructions?
maybe also, a chunky-to-planar instruction? although it's been said that the '060 can already max out the chipmem bus bandwidth with software c2p so maybe it isn't needed.
how about something to speed up the DCT and inverse DCT?
http://en.wikipedia.org/wiki/Discrete_cosine_transform
-
freqmax wrote:
Is there any features that the 68060 is missing that any programmer would love too see?, now that softcores are possible ;)
Softcores maybe possible, but they are not viable.
The FPGA's are either too slow, or too expensive to replicate an 060.
(Not to mention that no-one has yet made a HDL version of an 060 (or even an 030) because no-one knows for sure how parts of it actually work.
-
if softcores are available, i like to see a possibility to have access to core and can create own functions in FPGA.
in 99% of Software programs that run too slow, the program execute again and again only 50-200 asm instructions.
for example when do video encoding/decoding/audio there are a few functions that need 90% of the time.
this are IDCT fft and H264 deblock YUV->RGB RGB->YUV and scaling, but with better quality as GFX Cards do.
have this funcs in Hardware speedup apps a lot.on ffmpeg this funcs are written in SIMD assembler to get best speed.
currently ffplay on my very old AMD64 3000+ (real 1,8 GHZ) can play a wmv mp4 video 640*480 with max 95% CPU load.DVD.320*240 mpg videos need 17% cpu load.DVD need less than 95% CPU load.
there is no Overlay here and no asm instruction (pure C code).So the 68k CPU need yuv->rgb translation.but the use of no gfx card overlay have advantage that a window partly on top of video display is correct see.
native ffplay that use on windows overlay and SIMD ISSE in asm written code need 17% CPU load.
if there is a future define to have this funcs in HW, then its possible to change winuae too to support this with CPU instructions.
So i think its important for a softcore CPU to use the ability to do full operations in Hardware and not with single CPU instructions
On PC simular is see too.full HDTV decoding is too slow for a single X86 CPU.
they use the programmable directx pixelshader or GFX Cards to do this MP4 functions in HW faster a X86 can do.
and a FPGA with CPU softcore can have this feature more easy integrate, have access to full memory and beat a real 060 easy in overall performance
-
bernd_afa wrote:
So the 68k CPU need yuv->rgb translation
Easier to add a Y'CbCr gfx mode to the gfx chip (SuperAGA?).
-
>Easier to add a Y'CbCr gfx mode to the gfx chip >(SuperAGA?).
this help only on fullscreen video and no GUI, but with GUI, the whole AOS need change to convert the output to the new format.
-
A few suggestions that I think might be fun
1) Expanding the register width to 64-bit. You'd need to devise a new set of opcodes to support operations on them, however.
2) Saturation arithmetic would be an interesting addition, especially for graphics manipulation.
3) Allow address registers to be used for normal integer operations. There are times when you only need a few pointers but your code needs extra data registers.
The problem with all of these is finding an efficient way to implement them that preserves backwards compatibility.
-
Adding new instructions to 68k is pointless when there are no tools taking advantage of it.
-
itix wrote:
Adding new instructions to 68k is pointless when there are no tools taking advantage of it.
Step #2, write an assembler package exposing the new operations.
-
bernd_afa wrote:
this help only on fullscreen video and no GUI
Doesn't have to be.
but with GUI, the whole AOS need change to convert the output to the new format.
No more than an RTG gfx card with Y'CbCr overlay.
-
Karlos wrote:
A few suggestions that I think might be fun
1) Expanding the register width to 64-bit. You'd need to devise a new set of opcodes to support operations on them, however.
I'd mode it out like the x86, with a Long Mode. That way the 68k instruction set and architecture could be stripped of all those performance crippling addressing modes and remove all the dead weight instructions... :-)
2) Saturation arithmetic would be an interesting addition, especially for graphics manipulation.
Hmmm... just add an off the shelf SIMD unit, that can be used in "Long Mode"
3) Allow address registers to be used for normal integer operations. There are times when you only need a few pointers but your code needs extra data registers.
In Long Mode, all registers are equal, and 64bit ;-)
The problem with all of these is finding an efficient way to implement them that preserves backwards compatibility.
Long Mode... :-D
-
@bloodline
(http://extropia.co.uk/_temp/cj.png)
You're talking my language, reggie!
*points at sig*
-
Karlos wrote:
@bloodline
(http://extropia.co.uk/_temp/cj.png)
You're talking my language, reggie!
*points at sig*
I didn't get where I am today by looking at sigs! ;-)
-
Well, I'm enjoying the benefits of an x64 as I post. I didn't get where I am today without enjoying the benefits of an x64 whilst I post.
But, we're not one of those dreadful organisations that thinks an architecture is obsolete just because it isn't enjoying the benefits of an x64. Goodbye Reggie!
-
An interesting topic would be what this new "Long Mode" would look like... also are there any reserved/unused bits left in the 68k status register that could be used to signal which mode the CPU should be operating in?
-Edit- A quick look at my 68k manual, suggests that bit 11 is free for use in the system bye of the SR... sorted :-)
If I'm really honest, I'd want an ISA/Programming model very similar to the x86-64 as I really like it :roll:
-
I'd actually like an architecture that only has SIMD registers, but still allows "normal" operations on them.
To enable this, each instruction could support a "mask" where a 16-bit word describes which sub elements of the register pair in an operation are to be affected.
Consider this pseudo example (assumes 128bit wide registers):
add.b r0,r1
This would add the "bottom" byte in r0 to the equivalent byte in r1, leaving the rest of d1 unaffected.
Whereas
add.b r0,r1,#FFFF
would add perform the same operation on every byte and
add.l r0,r1,#A
would pefrorm a 32-bit add on the highest and middle words, leaving the rest unaffected.
One obvious complication would be the status flags. You'd probably want up to 16 of them in this instance. However, in every VM I've written for fun, I never bothered implementing condition code flags, relying instead on compare two operands and branch instructions.
-
Karlos wrote:
I'd actually like an architecture that only has SIMD registers, but still allows "normal" operations on them.
To enable this, each instruction could support a "mask" where a 16-bit word describes which sub elements of the register pair in an operation are to be affected.
Consider this pseudo example (assumes 128bit wide registers):
add.b r0,r1
This would add the "bottom" byte in r0 to the equivalent byte in r1, leaving the rest of d1 unaffected.
Whereas
add.b r0,r1,#FFFF
would add perform the same operation on every byte and
add.l r0,r1,#A
would pefrorm a 32-bit add on the highest and middle words, leaving the rest unaffected.
One obvious complication would be the status flags. You'd probably want up to 16 of them in this instance. However, in every VM I've written for fun, I never bothered implementing condition code flags, relying instead on compare two operands and branch instructions.
Could you not write a Macro Assembler for your shiny new x86-64 that assembles a Pseudo Assembly language (something close to the 68k asm we know and love) into only SSE3 instructions... using the traditional x86 instruction set only when absolutely necessary... it might be a fun proof of concept?
-Edit- Yeah lose the CCs... the Alpha never had them :-P
-
I haven't actually gotten into x64 coding yet. I'm still having too much fun with CUDA. Performance wise, PTX makes SIMD look hopeless.
-
Karlos wrote:
I haven't actually gotten into x64 coding yet. I'm still having too much fun with CUDA. Performance wise, PTX makes SIMD look hopeless.
I stay as far away from ASM as possible now, and let XCode and SDL worry about the hardware... but I downloaded the Intel EMT64 docs and read them in detail to ensure I had an understanding of what is going on on a modern x86-64 system... the x86's mmu is a work of genius :-)
-
@karlos:
3) Allow address registers to be used for normal integer operations. There are times when you only need a few pointers but your code needs extra data registers.
this has been already taken care of in so called 050 core if i recall right what ive red on natami forum
-
bloodline wrote:
...and let XCode and SDL worry about the hardware...
Eww. Bloody mac deviant. What's wrong with plain old gcc ? ;-)
-
wawrzon wrote:
@karlos:
3) Allow address registers to be used for normal integer operations. There are times when you only need a few pointers but your code needs extra data registers.
this has been already taken care of in so called 050 core if i recall right what ive red on natami forum
Yep, as well as single instruction conditional branches. The idea is to add instructions that reduce code size without slowing down the processor. Smaller code is faster and one of the reasons why the 68k performs so well with so little. The best instruction set changes would be the same ones that the Natami team is making because if every 68060 softcore/emulator uses the same instruction set then there will be better support for all.
I would recommend against going 64 bit for the 68k. It really doesn't need the extra memory addressing with it's small code and with the byte, word, long modes it presents problems. Amiga data structures like tags (32 bit) could be a problem also. You either go big and fast or stay small and efficient. Optimizing for big and fast would also make existing 68k programs run slower while making small and efficient wouldn't have much of an impact on older programs.
The 68060 is really a very good processor at integer math with some very nice features. It has much of the modern CPU technology but with smaller caches and lower clock speeds which it doesn't need as much as modern RISC processors. If Motorola had made them at least twice as fast, there wouldn't be as many people using Amiga emulators :-).
-
matthey wrote:
Yep, as well as single instruction conditional branches.
Single cycle? Exceptionally difficult / impossible on pipelined processors.
matthey wrote:
The best instruction set changes would be the same ones that the Natami team is making because if every 68060 softcore/emulator uses the same instruction set then there will be better support for all.
Let's see them implement the existing instructions, cache, FPU, MMU etc. before making changes ;-)
-
alexh wrote:
matthey wrote:
Yep, as well as single instruction conditional branches.
Single cycle? Exceptionally difficult / impossible on pipelined processors.
I said single instruction not single cycle. The instruction would take the same number of cycles as an integer instruction and branch but would load faster as the instruction would take only 1-2 words instead of 2-5. It would decode to the same thing in the pipeline. Kind of like the dbra instruction. It only takes 1 cycle more than a branch which is the same as a subq with word (BCC) branch but loads faster and uses the instruction cache more effectively. It would be more useful if there was a short (byte) version of dbra that was 1 word, if it could use a long decrement register, and it stopped at 0 instead of -1. The down side is that the logic is a little more complicated to deal with extra instructions but as long as it doesn't add new levels of logic (decoding) it shouldn't slow things down much. 68k and PPC prove that all out simple single cycle RISC processors don't have as much of an advantage as they do in theory. RISC processors need large and fast caches and memory, and high clock speeds and still don't perform very well in some complex operations. The best processor IMHO is between a RISC and CISC with a simple logical medium sized but powerful command set.
matthey wrote:
The best instruction set changes would be the same ones that the Natami team is making because if every 68060 softcore/emulator uses the same instruction set then there will be better support for all.
Let's see them implement the existing instructions, cache, FPU, MMU etc. before making changes ;-)[/quote]
Agreed. They should have started with a 68020 emulator first and clocked it up with much larger caches and a branch prediction cache like the 68060. Superscaler would be super difficult to implement and might not have any advantage in a FPGA or emulation. Emulating a 68060 is no small task and it would be nice if they could get something out in less than 5 years even if it's not as powerful as a 68060. The time to do software development is often underestimated.
-
Strictly speaking, is an FPGA implementation of an architecture considered an emulation?
-
I don't see the point in adding new instructions or addressing modes as it will only serve to frustrate people who want to run new code on original processors, and adding an illegal instruction trap handler to emulate them would slow things down a lot.
Larger caches would be nice though :-)
-
The primary goal should of course to be as simple as possible. And a 68020 can probarbly do everything that 030/040/060 can. Albeit slower.
My idea was if there were minor additions or bugs that one could have in mind when creating a softcore m68k.
Seems larger caches is one that could be implemented without wrecking compability too much. However any code should always have an switch to remain strictly compatible. Including bugs, as some software may rely on them.
A softcore 68020 is one stepping stone towards A1200,A3000,A4000,AGA etc..while there still exist original hardware to test any clones with.
-
I like the approach that the Natami team is taking with their vector unit. They want to make the vector unit a separate processor so that it can be processing while the main processor does something else.
I also like that they are stripping out the multiprocessor support to make the addressing modes more orthogonal on the 68050. This should make it easier to write compiler backends for it.
-
The 68050 is what used to be 68070?
-
@Kolla
The simple answer is yes.
The 68050 is not superscalar so it would not be fair to call it a 68070. We aim to make the 68050 be a 68040 juiced up on steroids, with the MMU & FPU amputated.
-
i dont think i ever seen the thermal sensing pins used,perhaps i missed somthing.
-
Ok, I did a quick search on google for softcore and what came up was not exactly what I call IT related .. so anyone can explain to me what softcore (the IT type) is?
Regards,
Sim085
p.s. - please don't laugh.
-
Ok, I did a quick search on google for softcore and what came up was not exactly what I call IT related .. so anyone can explain to me what softcore (the IT type) is?
Regards,
Sim085
p.s. - please don't laugh.
An FPGA description of a CPU core... Which can be used to synthesize a CPU using an FPGA.