Does Size Matter?

[Atheist]

It's too late, its' all been set in stone now.

But I would like to ask: and this is equally an AOS4.0 and MorphOS Q.

Now that we've gone the PPC route, are we doomed to bloated SW like on the PC?

CISC is smaller instructions, but decoded, they use the same amount of clock cycles (as several RISC commands) to execute.

While RISC is smaller 1 clock cycle instructions, and you don't use, on rare occassion, the instruction you don't need, unlike in a CISC, where all of the instruction is used, needed or not.

So, going RISC, we pay with overhead of HD space, and reading into ram from HD, and more ram needed, as well.

Are we ahead, at the same clock speed?

Then, when we go 64 bit, will instructions jump to 8 bytes long, and because of RISC, more instructions are needed than in CISC, bloating SW to collasol sizes?

Also, when they jump to 64 bit, how would windoesnot fare in the bloatware category? Should be scary!

This question is based on my limited knowledge of CPUs, OSs, and compilers, so try to fill in the holes where my statements are flawed.

[iamaboringperson]

Now that we've gone the PPC route, are we doomed to bloated SW like on the PC?

HELL NO! amiga and morphOS software will always be very compact

CISC is smaller instructions

if you mean smaller as in number of bytes, you're wrong. x86 instructions can be anywhere between 1byte and 20bytes wide! or more

but decoded, they use the same amount of clock cycles (as several RISC commands) to execute.

not quite - its actually quite a bit more complex than that...

So, going RISC, we pay with overhead of HD space, and reading into ram from HD, and more ram needed, as well.

as a general rule of thumb, RISC programs are roughly 1.5 times the size of CISC
but it depends on the software
so that just means that instead of an amiga executable of 1 meg, it might be about 1.5

of course, all the data that comes with it will be the same size. if its a game, the graphics and audio(which make up the bulk of any modern game) will take up the same space

Are we ahead, at the same clock speed?

cycle for cycle? we sure are!

This question is based on my limited knowledge of CPUs, OSs, and compilers, so try to fill in the holes where my statements are flawed.

sorry, but some of your questions/statments i didnt understand! ;-)

[Karlos]

@Atheist

You keep asking this one :-)

Look, a 64-bit processor does not necessarily imply 64-bit opcodes. It may be true of some VLIW architectures but it is not universally so.

64-bit means that the processors can operate directly on 64-bit integer and pointer operands (thereby breaking the 4Gb physically addressable memory barrier).

The 68020+ are all true 32-bit processors. However, the typical 680x0 opcode size is still defined in the 16-bit words used on the original 68000. 68020 code is not 2x the size of 68000 code by virtue of being truly 32-bit...

In a similar fashion, the 32-bit PPC instruction set is 32-bits wide. The 64-bit implementations will still use 32-bit sized opcodes, if they dont they wont be code compatible with the earlier 60x / G3 / G4.

Ultimately the change is that the size of the general purpose registers has expanded to 64-bits wide and some new instructions exist to handle 64-bit data.

I hope this clarifies it for you a bit :-)

-edit-

The statement about CISC v RISC clock cycles is not true. Most modern CISC architectures (x86 in particular) break a CISC instruction down into a series of micro operations that are then fed to multiple execution units. This decomposition is a complex process.

The core of the chip borrows heavily from RISC design paragdims, using strategies such as pipelining, rename registers etc.

Basically modern CISC chips only reach the performance they do by copying RISC ideas internally. Its basically a kludge.

If you think of an x86 executing several micro ops from a single CISC instruction in parallel, consider a genuine RISC processor will be executing several RISC instructions in parallel. Its common for current RISC cpus to complete several instuction every cycle :-D

[iamaboringperson]

The 64-bit implementations will still use 32-bit sized opcodes,

thats the bit that i was unsure of! :lol: (at times im to lazy to go and do the research myself)

Idea* idea = new Idea(random());
while (idea->isCrap()) {
  delete idea; idea = new Idea(random());
}

:lol: karlos! i think you have just exposed the secrets to human inteligence! i could imagine pretty soon you will have a software human being(AI) in its beta testing stage ;-)

[Karlos]

iamaboringperson wrote:

The 64-bit implementations will still use 32-bit sized opcodes,

thats the bit that i was unsure of! :lol: (at times im to lazy to go and do the research myself)

The PPC instuction set is completely orthoganal AFAIK. Adding opcodes that are 64-bits wide would really screw it up :-)

karlos! i think you have just exposed the secrets to human inteligence! i could imagine pretty soon you will have a software human being(AI) in its beta testing stage ;-)

Like a real human, memory fragmentation over time will cause this algorithm to break down (unless were lucky enough to get the storage for idea recycled each time that is ;-))

[Atheist]

I just noticed that new sig too.

I feel like the delete command may apply  to my, indeed I have asked the question a few times, post.

I'm just lamenting the fact that I was hoping that almost the whole OS could reside in flashrom on the motherboard, like before. But the OSs are getting bigger (a necessity), then there's the crazy size of the graphics board drivers and audio card. I was hoping the return of easy computing, like the old Amiga days. I mean, we had stereo sound, how big was the driver? Or the AGA drivers?

A1!

[Karlos]

Fear not :-)

Whilst the code will doubtlessly increase in size by 50% or so, think how compact the OS actually is.

AmigaOS (and MorphOS and AROS) stick to the amiga notion of using lots of shared code, the vast majority of which is fully reentrant.

Windows, by comparison, is extremely bad at this, it's not uncommon to have several instances of the same .dll in memory, which defeats the whole purpose of dlls :-) Hell, if you go into Win2Ks advanced options you'll find the option to run every window task in seperate code space (the idea being that its more stable than allowing reentrant behaviour :lol:).

Add to that the need for huge memory buffers to hide the inadequacies of the filing systems, lazy programmers and the assumption that the end user will always buy more ram and you get the present nightmare.

We have some really unique concepts to our OS too. Datatypes are one such example that reduces an applications dependency on having its own code to load/save data. Contrast that to other platforms where every app is resposible for such things and you can see how they bloat.

Amiga programmers, long since attuned to the need for compact, fast and reusable code to get the performance on our 'older' hardware have the opportunity to create a whole new wealth of applications on the new hardware. We live in interesting times :-)

:-D

Irrespective of the CPU type, satan himslef will be skating the ice to work the day any incarnation of AmigaOS and its applications requires anything like the resources Windows does :-)

[iamaboringperson]

QNX's kernal is apparently 32k for x86's, and about 48k for RISC CPU's

not a huge difference

remember also, that windows NT was almost equaly as bloated on RISC hardware as it was CISC - it wasnt a great deal larger

[iamaboringperson]

Idea* idea = new Idea(random());
while (idea->isCrap()) {
  delete idea; idea = new Idea(random());
}

looks like you are using a read-ahead type loop there, im usually picky about read ahead loops since in most languages they can be easily avoided by replacing a while loop with a do ... while :-)  then you have a wee bit less code ;-)