View Single Post
Old 04 May 2017, 00:58   #186
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Originally Posted by wawa View Post
if amiga, and i mean 68k is to take advantage of cross platform developments, not only from linux but also whats openly available among the widely understood amiga(ng) scene, one needs to accept common standards. and that is gcc toolchain whether we like it or not.
No doubt GCC is still the standard by which all compilers are measured. The only problem is there is no official Amiga support and it is in many ways alien to the Amiga.

Originally Posted by wawa View Post
advantages of gdb usage along with winuae are obvious i think, i knew people got it to work, but the one i knew, jason, has quit..

imho, we need to establish kind of workflow that allows more people to work on stuff and contribute. and debugging 68k is an open problem here. im really tired of putting debug statements and breakpoints all over the code. it is error prone, tiresome and extremely time consuming.
Part of the problem is the alien debugging format. GDB is really not that easy to use either as it makes sacrifices to be cross platform. BDebug is much easier to use and has some support for GCC formats. It would be a good software to try and open source. I would work on improving it if the source were available. I have considered adding an Amiga GUI to ADis and turning it into a debugger/disassembler but I will not bother if the 68k Amiga is going to go nowhere.

Originally Posted by E-Penguin View Post
Definitely. The Vampire / Apollo project are galloping towards an Amiga-on-a-chip, but not just recreating the old hardware; they're developing new features. Whether they're doing it right seems to be a matter of some debate, but they are doing it. It must be possible for others. Open sourcing the Apollo core and associated custom chip enhancements, or an equivalent M68k hardware design, is as critical as for software.
Yea, it makes sense to move everything possible into one big FPGA (future SoC?). IMO, the Apollo guys are doing some things right and some things wrong. I'm still amazed about some of the poor CPU ISA choices for the future. Why create problems and limitations for later by over-optimizing for particular hardware today? Gunnar has even entertained the possibility of an ASIC but I would not invest in one with the choices he made. In contrast to the Apollo guys, the FPGA Arcade group has no vision for a future 68k outside of a perfect simulation of existing 68k processors. They look for shortcuts like partial emulation using ARM and seem to miss the potential that was overlooked in the 68k. Mike appears to be more than capable of 68k FPGA CPU design too. An ASIC from his 68k design may not be quite as fast but may be better organized and easier to work with. You can probably tell that I believe a 68k ASIC is the next step in the natural progression, probably without the Amiga (or other system) custom chips which would be left in a smaller cheaper FPGA for flexibility.

Originally Posted by E-Penguin View Post
With a bigger / faster FPGA it isn't outlandish to consider a multi core, gigahertz class M68k implementation in the near future. That might actually have enough poke to challenge low end ARM devices (though not on cost).

Modern FPGAs and VHDL are making open source chip design a reality.
Multi-core support is relatively easy in an FPGA (copy and paste) and is a quick way to better compete with an ASIC in performance. The down side is the need for a larger FPGA which becomes less cost effective. This is acceptable for an FPGA design for an ASIC. Muti-core is a much better way to increase performance than high clock speeds for ASICs also. The Apollo Core (and 68060) already outperforms most low end ARM processors in single core performance per MHz. CISC processors are naturally strong in single core performance and the ARM's Thumb 2 is inferior to the 68k ISA (8 GP registers compared to the 68k 16 which increases cache/memory accesses and the number of instructions compared to the 68k and 68k enhancements can decrease the number of instructions while improving code density).
matthey is offline  
Page generated in 0.04324 seconds with 10 queries