Next gen Amiga

[robinsonb5]

Originally Posted by kolla

So why are there so few x86 phones around?

Because in a handheld device the emphasis isn't on raw number-crunching performance - it's on power efficiency. If the web weren't such an unholy bloated javascript-ridden mess these days phones wouldn't need even half the processing power they currently have.

[meynaf]

Originally Posted by kolla

So why are there so few x86 phones around?

Anyone can license arm and start building SoC based on them. For x86 it's a little more complicated.
Besides, x86 has too much legacy to handle for being power efficient.

[alexh]

Originally Posted by meynaf

Anyone can license arm and start building SoC based on them.

Or make their own one based on the ARM2 architecture

[Megol]

Originally Posted by alexh

Or make their own one based on the ARM2 architecture

Anything up to ARM version 5 should be possible to do, first released in 1998 so ca 20 years ago.

[Megol]

Originally Posted by meynaf

What difference would you want to make then ?

Something worth spending my time for. Like maybe getting somebody to realize things aren't based on personal ideas but facts.
If one instead get repeatedly insulted in a way that shows the others in the "discussion" can't even be bothered to read there's no value to gain.

When i wrote "unreadable", i didn't ask for an explanation. I just wanted to point that what the thing does isn't obvious and requires some amount of deciphering. This has a bad effect when reading code.
(This is a general statement ; instructions doing several unrelated things together make code harder to read.)

Yes 68k is best. When 68k does several things in one instruction it is good, otherwise not.

Yes but why would one want to do that ?
When i wrote "for what", i asked for a concrete case.
One can easily invent an instruction that does the job of many others, but if no program ever has these instruction sequences then it's pointless.
And that is more or less the case here.
Something like 90% of instructions in a typical ARM stream start with "E" (for "always true" condition) and not 10% will use the barrel shifter (i'm giving these from memory, if you think it's wrong then you may just disassemble code and make your own statistics). In fact it's similar to the use of branch and shift instructions in any other architecture.

And how is that relevant to this thread? Did you see me making any claim about the frequency of use?

An example you could give is a real life routine, not just "clear a bitfield if some val is negative" (which btw is doable in 3 instructions in 68k rather than 4, but still not very useful).
How many instructions, for example, to read a decimal number from a stream ?

That isn't even a question. You specify nothing.

This is purely implementation-driven decisions, and perhaps you know or can guess what i think about these.

Yes, 68k good - otherwise bad.

Perhaps it would be interesting to list all the shortcomings and attempt to fix them (for a purely academic purpose).
First thing to get is a complete instruction set encoding reference table and so far i've been unable to merely find that. It seems every model has own instruction set and it doesn't help.

The simplest possible English language search for "ARM instruction set" get the results.

The rest is nonsense, especially for someone liking the 68k architecture.

Requiring less transistors yes, but not faster anymore.
RISC was an advantage in the past as it could implement relative costly methods for executing instructions fast (things like OoO, etc) but now there is a wealth of transistors and they have no advantage left.
This is why ARM is beaten in performance by x86.
This is also why IBM had to use exceedingly aggressive designs for POWER8 to still be able to compete (and it does only in floating-point).

If you have to execute more instructions for doing the same job, today it's not possible to be faster. As simple as that.

Sad how that's not how it works. I've described some of the problems in the past and will not do that again.

Unlike your characterization of me I've "defended" CISC designs in the past and tried to illustrate they aren't as bad as RISC extremists liked to claim. That doesn't mean that RISC isn't easier to execute faster and wider (superscalar) than CISC, especially in an FPGA.

[meynaf]

Originally Posted by Megol

Something worth spending my time for. Like maybe getting somebody to realize things aren't based on personal ideas but facts.
If one instead get repeatedly insulted in a way that shows the others in the "discussion" can't even be bothered to read there's no value to gain.

You did not get insulted in any way. But when you write wrong things what can you expect in return ?
You say you want facts but that one will not attract coders with a bogus instruction set is a fact.
Comparing instruction sets with real examples also leads to facts.

Originally Posted by Megol

Yes 68k is best. When 68k does several things in one instruction it is good, otherwise not.

You will hardly find any sufficiently sized routine where another cpu family can do it in less instructions.
Keep in mind that what matters is the average number of instructions.

Originally Posted by Megol

And how is that relevant to this thread? Did you see me making any claim about the frequency of use?

Indeed you did not make any claim about frequency of use, missing an important point.

Originally Posted by Megol

That isn't even a question. You specify nothing.

It wasn't meant to be a question. I just told you how a good example could look like.

Originally Posted by Megol

Yes, 68k good - otherwise bad.

Sadly.

Originally Posted by Megol

The simplest possible English language search for "ARM instruction set" get the results.

Nope it does not.

Originally Posted by Megol

The rest is nonsense, especially for someone liking the 68k architecture.

Do not qualify as nonsense something you simply do not understand.

Originally Posted by Megol

Sad how that's not how it works. I've described some of the problems in the past and will not do that again.

I don't remember the details but what you wrote in the past has been contradicted. So yes you'd rather not repeat it over and over.

Originally Posted by Megol

Unlike your characterization of me I've "defended" CISC designs in the past and tried to illustrate they aren't as bad as RISC extremists liked to claim. That doesn't mean that RISC isn't easier to execute faster and wider (superscalar) than CISC, especially in an FPGA.

Today this really does not matter anymore.

[Mr.Flibble]

IIRC most processors these days are a hybrid of both CISC and RISC, and have been that way for a very long time now.

[hth313]

Instruction sets are for most people highly irrelevant these days.

Very few people care about them, not even me (apart from I do not like x86 very much), and I work with them on a daily basis and have probably worked with some 20 different architectures over the years.

You just use what is at hand, and the vast majority of people do not even see it and could not care less.

Of all aspects of a computer platform I think this must be one of the least important ones.

[meynaf]

Originally Posted by hth313

Instruction sets are for most people highly irrelevant these days.

Very few people care about them, not even me (apart from I do not like x86 very much), and I work with them on a daily basis and have probably worked with some 20 different architectures over the years.

You just use what is at hand, and the vast majority of people do not even see it and could not care less.

Of all aspects of a computer platform I think this must be one of the least important ones.

It is the basis of everything and people just don't care. Instruction set is the most overlooked part, the reason why todays computing is so boring.

[hth313]

Originally Posted by meynaf

It is the basis of everything and people just don't care. Instruction set is the most overlooked part, the reason why todays computing is so boring.

Yes, I find instruction sets interesting and fun. It is amusing to work with both odd ones as well as the more friendly ones.

However, the rest of the world is not at all like this.

When it comes to the Amiga I could not care less whether it runs 68K or ARM. They both have their advantages and disadvantages and but I think both are viable alternatives. I just do not want the Amiga on x86 (which is too common and too boring) or PPC which is incompatible with 68K, expensive and a dead end.

[meynaf]

Originally Posted by hth313

Yes, I find instruction sets interesting and fun. It is amusing to work with both odd ones as well as the more friendly ones.

However, the rest of the world is not at all like this.

When it comes to the Amiga I could not care less whether it runs 68K or ARM. They both have their advantages and disadvantages and but I think both are viable alternatives. I just do not want the Amiga on x86 (which is too common and too boring) or PPC which is incompatible with 68K, expensive and a dead end.

PPC could not really replace 68k and there are good reasons for this.
ARM will not fare better and for the same reasons.

The whole problem is that many people don't value the isa because they just don't see it directly - while nonetheless it's the basis for everything.
Amiga could run multitasking OS in 512k because the whole cpu architecture permits this. Next time you run a demo that does unbelievable things, use some system patch or even play a whdload game, remember that it would not have been possible with arm instead of 68k. Of course none of my Atari ST to Amiga game ports would have been doable in a decent amount of time.
And it is because for these tasks (and many others), having an abstraction layer around the cpu is not possible.

[E-Penguin]

There are Unix ports on STM32s, so there's nothing intrinsically wrong with ARMs in terms of supporting complex functionality on limited resources. I'm just getting into M68k asm but from what I've seen so far it's not got anything particularly unique compared to other instruction sets. (I'm fairly used to unusual architectures. MIL-STD-1750A anyone?)

[meynaf]

Originally Posted by E-Penguin

There are Unix ports on STM32s, so there's nothing intrinsically wrong with ARMs in terms of supporting complex functionality on limited resources.

Seems we don't define "limited resources" in the same way.

Originally Posted by E-Penguin

I'm just getting into M68k asm but from what I've seen so far it's not got anything particularly unique compared to other instruction sets. (I'm fairly used to unusual architectures. MIL-STD-1750A anyone?)

It does not need to possess anything particularly unique. It's just a nice mix of everything one needs ; matter of balance rather than specific features.

To have a good view on this, the best way is to write the same code in different architectures, and compare. I asked for such comparisons in the past and noticed that while 68k code is easy to get (just ask here in coders.asm area), oddly nobody really shows code of other architecture to compare with. People just grumble architecture x, y or z is better than 68k or on par with it, without showing actual code to prove their claims (single instruction examples do NOT count).

[Kalamatee]

The only thing ive gotten from this thread, is most of the people participating don't really know what they are talking about, and confuse opinion with fact.

[Dunny]

Hell, instruction sets were irrelevant to me back in the 80s - all they were was a way to tell the silicon how to do what I wanted it to do. The end result was the goal, be it z80, 6502, 68k, x86 or ARM. Still is, tbh.

[kolla]

Fun fact - I just got AROS/68k booting on the MiSTer (and the trick should work on MiST too)

After I noticed how LoadModule was able to load PeterK's icon.library, it dawned on me that I should try with scsi.device, so I put LoadModule and scsi.device 43.45 ("A300" version) onto the AROS bootfloppy, copied over ADF and HDF (with pfs3aio partitions btw) to the MiSTer and tada... after loading scsi.device with LoadModule, removing floppy and reset... AROS boots perfectly fine into DOpus desktop

Then I tried installing HighGfx (http://aminet.net/package/driver/moni/HighGFX40_6), but it looks like running AmigaOS monitor definitions doesn't work, they just hang when I try to run them manually, and no modes show up in screenmode.

Speedwise, AROS is quite usable on 40ish MHz 030 speeds, just needs trimming down the settings to match those of OS3.x

[Kalamatee]

Originally Posted by kolla

Fun fact - I just got AROS/68k booting on the MiSTer (and the trick should work on MiST too)

After I noticed how LoadModule was able to load PeterK's icon.library, it dawned on me that I should try with scsi.device, so I put LoadModule and scsi.device 43.45 ("A300" version) onto the AROS bootfloppy, copied over ADF and HDF (with pfs3aio partitions btw) to the MiSTer and tada... after loading scsi.device with LoadModule, removing floppy and reset... AROS boots perfectly fine into DOpus desktop

Nice =)

Then I tried installing HighGfx (http://aminet.net/package/driver/moni/HighGFX40_6), but it looks like running AmigaOS monitor definitions doesn't work, they just hang when I try to run them manually, and no modes show up in screenmode.

Yes monitors are quite different on AROS (infact they are just hidd chipset drivers)

Speedwise, AROS is quite usable on 40ish MHz 030 speeds, just needs trimming down the settings to match those of OS3.x

[kolla]

Originally Posted by Kalamatee

Nice =)

Yes monitors are quite different on AROS (infact they are just hidd chipset drivers)

Yes, not sure what would be the best option for AROS on real Amiga chipset, overscan settings is another problem that would need work.

Anyways, I took some photos and dumped them on dropbox

https://www.dropbox.com/sh/2uwo9zk03..._Jvf1H8Aa?dl=0

[AdvanceFollow]

Originally Posted by kolla

So why are there so few x86 phones around?

Intel couldn't make it profitable. There are so many companies licensing ARM and making their own smartphone and tablet SoCs at very low prices. Intel tried to undercut them and were basically giving away Atom chips for free and losing tons of money, so they eventually canceled the Atom line altogether (the architecture still lives on in some Celeron branded chips). The profit margins in the smartphone/tablet space were just too slim for a company like Intel.

The actual SoCs were actually quite competitive. The Z3580 in the Zenfone 2 traded blows with the latest Snapdragon at the time and didn't sacrifice battery life.

[wawa]

Originally Posted by kolla

Yes, not sure what would be the best option for AROS on real Amiga chipset, overscan settings is another problem that would need work.

deadwood proposed once such mini bounties here but eventually got disencouraged and left. i carry part of responsibility for that becasue i have explained him that interest was still too low for this to take off and aros needed fixes in advance to even have chance to get accepted let alone embraced by wider m68k audience:

http://eab.abime.net/showthread.php?t=80344&page=4

what concerns monitors i have spoken to thor about it much much longer ago and he actually wasnt in favour to implement it in aros. he considered it an undocumented hack and preferred aros implement this kind of preferences in a clean even if incompatible manner, as it actually does.

Anyways, I took some photos and dumped them on dropbox

https://www.dropbox.com/sh/2uwo9zk03..._Jvf1H8Aa?dl=0

cool. is that superhighres interlace? something like this can be pretty neat and even usable on a tft