BFINS D0,(a0){d1:3}
   ADDq.l #3,d1
  

    BFINS D0,(a0){d1:3}
    ADDq.l #3,d1
   

I probably make an example:

void PutBits(UBYTE n,ULONG bitbuffer)
{
   assert(n > 0 && n  m_ucBits) {
     // If so, output all bits we can.
     n -= m_ucBits;   // that many bits go away 
     m_ucBuffer |= (bitbuffer>>n) & ((1

    BFINS D0,(a0){d1:3}
    ADDq.l #3,d1
   

I probably make an example:

Posting doesn't work... I'll write an email.

BFEXTU should work alike, just in the opposite direction.

Greetings,
Thomas

So, my answers aren't related to Natami, but I'll give now some. ;)

Cesare Di Mauro wrote:   1) Lack of a modern SIMD unit (CPU)     A SIMD UNit can be added to the 68k in a clean compatible manner   But SIMD is useful for a fraction of software only.   While a good INTEGER unit is always needed.

Sure, but I think that Motorola 68K ISA is mature enough (that doesn't mean that NO more changes are needed!), whereas a new SIMD unit opens up a new world of possibilities.

Also, if you take a look at x86 evolution from the MMX introduction, you see that a few changes were made to the "core" ISA, reserving HUGE changes to the SIMD side.

Needs are changing over the time. Massive intra-parallelization (SIMD) and inter-parallelization (multicore -> SMP or AMP) are common these days.

Cesare Di Mauro wrote:     2) Lack of SMP (OS)   Well we can certainly live without it.

 
We already discussed about this. SMP isn't a problem for Natami, since it will never be a multi-FPGA project (Claudio also stated this).

So, monitoring the nested ExecBase's task count can be made relatively cheap and efficient, in order to allow SMP even on an (new) "Amiga platform".

FPGAs are becoming more and more capable, and you said that copy & pasting a 68K core is just a joke.
That's why you chose 68K ISA for "Robin".
That's why you can add more general purpose 68K cores in SMP configuration, when more space (and time ;) will be available.

Cesare Di Mauro wrote:       3) Stack frames make interrupts and traps expensive. Shadow registers ala-ARM or FIDO are a better solution in terms of speed and latency. (CPU & OS)   But interrupt handling never was limitation on AMIGA.

It depends strictly on what kind of usage you make of interrupts or traps.

Think about trapping the unsupported Integer or FPU opcodes for 68040 or 68060 in order to emulate them: it was VERY EXPENSIVE.

As an emulator writer, I was fascinating about the idea of using MMU's page fault mechanism to trap accesses to specific guest emulated area, in order to do useful work without killing the whole emulation speed.

Just to make an example, suppose that I want to emulate an x86 with full VGA support. Normally I need to check EVERY (guest) memory read or write, in order to see if it targets the VGA segments (which ranges from A0000 to BFFFF), and make specific operations based on the current VGA memory mapping (which is quite a mess for 16 colors modes or X-Modes).

Those checks eats up MUCH performance, even if you never address VGA's memory in the executed applications.

Using an MMU with faulting pages mapped on A0000-BFFFF guest memory pages can make the emulator running at full speed on normal memory access (the guest memory can be addressed without checks at all!), trapping only on VGA's pages. But if traps are slow, they can kill performance for VGA accesses.

That's why a light-weight trap mechanism such as the one on ARMs or FIDO can be very useful. Emulators can run pretty well on such systems, with properly written code.

Cesare Di Mauro wrote:     6) Lack of resource tracking, virtual memory, and memory protection (OS) I agree that resource tracking is something very good. But Virtual memory is fluff.

It's questionable. ;) The problem here is AmigaOS, which makes it very difficult to implement, but some applications where made even on AmigaOS to let it usable.

Memory protection is mainly a kludge - and in a DMA driven system like the AMIGA it can by desing never work to 100%.

It's true for Amiga, not for a SoC such as Natami. That's talking only at the hardware level.

On the software side, memory protection is a big problem for AmigaOS, unfortunately. 

Cesare Di Mauro wrote:     7) Lack of GUI enhancements, such as vectorial graphic presentation (OS) Taste is a personal matter but I would consider this fluff.

Retargetting graphic keeping fonts and graphics at the maximum quality every time isn't fluff, but a nicer feature.

Take a bitmap and zoom and/or rotate it whatever you like. Now do the same with a PDF or a vector image (SVG, Adobe Illustrator). The difference is HUGE.

That's were modern operating system are going.

Cesare Di Mauro wrote:       8) Lack of modern transactional/journaled filesystem, with metadata support and large storage (OS) PFS?

I doesn't support large storages.

Also, I haven't found technical stuff about its robustness (journaling) and metadata handling, but that's a problem of mine. :P

Cesare Di Mauro wrote:     9) chip / fast memory subdivision which makes no sense if the available bandwidth is almost the same. It makes sense only if we have chip mem = embedded or graphic memory with enormous bandwidth compared to the main memory. (Hardware) I think the opposite is true, my friend.   The logical Chip and fast subdivsion was very important for the AMIGA. This siperation is a clever and simple way to create a working syncronise beetwen chipset and CPU. Without this seperation no AMIGA with cache and without a MMU would have ever worked.

You are talking about early and/or lower-ends Amiga Systems. Amiga 3000 and 4000 had a full MMU, and the same was true for most accelerator boards.

Now in 2010 you have MMUs available even on potato chips. :P

Natami have several options to address this problem. You can add a PARTIAL MMU in order to mark memory that was allocated as "chip ram", and let the system be coherent.

A better option, which doesn't require operating system patches, will be to add bus-snooping logic to monitor memory changes made by the "custom chipset" part, and update CPU's memory cache.
Natami is a SoC, so it can be cheaper than a multichip system.

At this time I think that it is a waste to have chip and fast with similar bandwidths, but logically separated. With such low bandwidth available, it's quite better to let the system use all the memory bandwidth based on runtime needs.

It'll be a totally different question if you had an asymmetric system, with the chipset part having an order of magnitude more bandwidth compared to the main memory's one, such as the CPU vs GPU bandwidth on PCs or on XBox 360 (which has massive bandwidth available thanks to its e-DRAM).

Cesare Di Mauro wrote:       10) Lack of multiuser support (OS)   I would say this is only important for Server but not for homecomputers.

I used it in '94/'95, when I was working on Fighting Spirits, thanks to MultiUserFileSystem (I don't know if someone else remember it) with my plain Amiga 1200.

I use it right now in my desktop to have limited and controlled access for my wife, children and... me too. ;)

    BFINS D0,(a0){d1:3}
    ADDq.l #3,d1
   

Reason for that is the bitstuffing in JPEG and JPEG 2000. JPEG inserts a zero-byte after each 0xff byte, JPEG 2000 inserts a zero-bit after each 0xff byte.

So long,
Thomas

By bottlenecks, i was thinking about the parts who are actually a brake in the Amiga architecture. Like the planar who was great for 2D but who was a pain in the a.. for raycasting and other stuff (i'm not telling that planar is crap, but if the 1200 had some chunky modes too it was great), or the "chip" and "fast" ram concept.

SMP or Multiusers could improve things, but they are not there, and so, they are not slowing down the Amiga.

My first idea was to list most of the existing weaknesses of the Amiga and maybe find some that the team missed.

But it's also true that people like Gunnar, Thomas and you are better than me for that topic.

A program in startup sequence that you use to log in, then assigns folders for each user,moves files like user-startup and prefs, etc...

Obviously nearly no security, but would give the illusion of multiple users to the users, and still be compatable with all software.

Amiga has always supported parallelism in hardware.  SMP is just a shortcut for CPU manufacturers that don't want to design custom cores.  The Amiga way is to design custom processors to run in parallel.  I think that an SPU-like non-symmetric processor is the proper solution for parallel processing on the NatAmi.

If I refer to proposals relating to JPEG and other specific use, would it more appropriate to extend the instruction set according to general purpose? Or will there be commonly re-employ those new instructions?

Thanks

Regards bottlenecks and weaknesses of the Amiga (hardware), I wrote an article some time ago.
The original in italian is here: EXTERNAL LINK and a rough translation with Google here: EXTERNAL LINK  Its quite technical and you have to know some internals on how the Amiga chipset worked (there are links inside to other articles that explain them).

MultiUserFileSystem worked and works quite well: EXTERNAL LINK ;)

The (extreme) synthesis is that Thomas said that SMP isn't possible on Amigas, particularly because of the ExecBase:
BYTE TDNestCnt; /* task disable nesting count */
contention between the CPUs cannot be controlled, since this global variable can and WAS (sic!) be accessed directly instead of using the Forbid API.

Gunnar's response was that Natami can have direct control over this memory location (remember that we are talking about a SoC), regulating the access and contention between the CPUs.

Do you know of other problems that SMP can raise on Amiga?

As a professional, I must keep in mind the needs and requirements about a problem, evaluate the cost / benefits of the tools available, and chose the "better" solution.

Certainly I cannot discard some tools just on an empathy basis.

The Amiga way is to design custom processors to run in parallel.  I think that an SPU-like non-symmetric processor is the proper solution for parallel processing on the NatAmi.

But you are just translating the problem here, with a Cell-like AMP.

In such system you still have an SMP system with multiple symmetric cores working together to solve the problem(s).

The difference stays in a single element, the PPE, which works as the "master" / arbiter / controller of the SMP subsystem. This mode is called PPE-centric in the Cell literature.

However, there's another mode which is called SPE-centric, whereas the SPE self-regulate themselves without PPE intervention. This looks as an SMP system with NUMA, with the addition of some useful synchronization directives between the cores.

Anyway, you still have an SMP. It just changes how it used by the system, but in the end you have a number of identical cores on which distribute the work. So you have to think about dividing the problems in subproblems to parallelize, the same way you do with and SMP system.

Certainly an AMP approach is preferable on Amiga, since SMP poses big problems, as we know (unless Gunnar solves them! :D). So I'm with you here: in Natami it'll work more "natural".

But I pretty like that the additional cores being 68K derived, since I really like this architecture and I'll find cumbersome having to program with two different ISAs, such is in the Cell.

I think that we cannot have JPEG-only instructions, such as seeking the bit stream to find a $FF byte written or read (in order to put/discard $00 byte or a 0 bit, as it was made in JPEG and JPEG 2000).

But a general instruction set to work with bit streams helps A LOT on many areas, and can make the code FASTER (and compact, also).

A multi-cycle instructions solution is preferable instead of have nothing.

Just to be clear, I don't care if the pipeline stalls for one or more cycles, waiting for its result. The most important thing is that it works solving a problem that on other architecture will require MANY cycles and introduces A LOT of data dependency, slowing down the execution.

The only question is about the compiler support for such useful things, that can be really problematic to solve (how to recognize those patterns and emit proper code?).

Looks more like a trick than my approach :p

Besides, changing file system will no doubt cause problems somewhere.