Congratulations!

Good job!

We need to clone the Doctor and clone the other guy that's working on SkyOS.

_________________
- Ronald

All beer tastes bad.

So what are the advantages compared to 32 bit ? I always wondered...

Is it faster (on 64 bit CPU's) and if yes, what is faster and how much faster ?
Does it have more possibilities ?
Does it alow applications to run better, faster or more stable ?
What advantages does 32 bit applictions have ? if any...

Mart

_________________
Theres a time to live and a time to die
When its time to meet the maker
Theres a time to live but isnt it strange
That as soon as you're born you're dying

Congrats!

What are the advantages please?

_________________
Sent from my Quantum Computer.

Surely you mean DIS-advantages? More incompatibilities, confusion and problems?

I dont think there are any (real world) advantages.

Great progress. Who could have thought AROS would be first.

_________________
AmigaOS or MorphOS on x86 would sell orders of magnitude more than the current,
hardware-intensive solutions. And they'd go faster.-- D.Haynie

Now merge OS4 and MOS into the code and we have ALOT of new HW :)

Most impressive! Congratulation Finally an AmigaOS for the future Amiga Inc, i hope you can manage this with the much-promised OS5..

_________________
Helge K. Leaving the Amiga in favour of a PC..

nice news

sadly the aros-live cd dont like my onboard radeon xpress200 for higher resolutions. Try differtent boot options, it allows only small resolutions and in that case it doesnt recognize my usb-mouse (its plugged into a usb-hub). Maybe i have to try to plug the usb-mouse directly to an usb-output and not to that usb-hub.

Hints anyone?

Last edited by agnuz6569 on 10-Oct-2007 at 07:21 PM.

_________________
Charly says always tell your mummy before you go off use some other os!

@benji
Quote:

Surely you mean DIS-advantages? More incompatibilities, confusion and problems? I dont think there are any (real world) advantages.

That's the price of EVOLUTION, unless you want to rely on ancient hardware forever, that is... I'm quite happy with some of the DIS-advantages it wil bring, such as Memory Protection, Resource Tracking...

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@agnuz6569

USB is a recent thing, if it is of consolation, Vista gives lots of problems with USB and it's Vista...

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

The AROS icon set needs much improvement; it looks to kiddish to take seriously!

_________________

Quote:

So what are the advantages compared to 32 bit ?

You can address more than 4GB of RAM.

_________________
Sam

Quote:

You can address more than 4GB of RAM.

GREAT ! What else ??

_________________
Theres a time to live and a time to die
When its time to meet the maker
Theres a time to live but isnt it strange
That as soon as you're born you're dying

@Metalheart

Move larger blocks of data faster maybe and more precise floating pointer values maybe,

64bit is twice as large as 32bit, so if you write program and decides use 64bit to hold a counter value that will contain a value from 0-255 you wasting 7 bytes of memory, and your RAM buss will need to deal whit it (slower more bloated applications, because the wasted ram will need to swapped out to disk, when your physical memory is full)

I think the move from 16bit to 32bit was important because we needed larger numbers,
The move from 32bit to 64bit is not that fantastic, how ever there is some usefulness in having more virtual address space, there some cool tricks you can do whit the MMU that might make it worth while, you can do the same tricks on 32bit but you do have only 2 or 4Gbyte form address space to play whit, watch means virtual address space is best used program using the MMU for tricks free the virtual address space, so other application can use the same address space when they need to, virtual address space can be used to deferment memory, or load blocks from disks on memory read or write, or copy on write trick, a more useful trick might be endien conversion on write or read, it can also be used to emulate none existing custom chips in memory, the MMU is really a fantastic piece of hardware.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

Poster: NutsAboutAmiga Date: 11-Oct-2007 16:37:52 @Metalheart Move larger blocks of data faster maybe and more precise floating pointer values maybe,

Not,really, you can do this with floating point (64bit) registers already.
Floating point registers are already 64bit so no difference.

Quote:

64bit is twice as large as 32bit, so if you write program and decides use 64bit to hold a counter value that will contain a value from 0-255 you wasting 7 bytes of memory, and your RAM buss will need to deal whit it (slower more bloated applications, because the wasted ram will need to swapped out to disk, when your physical memory is full)

Yes, to some degree this is true. 64bit is normally actually slower, although
on average not much. Depends on the actual hardware too.

_________________
Selur erutangis siht

In the IEEE 754 standard as used by most floating point implementations the registers are 32-bit for single precision, ?43-bit for single extended precision (not really used), 64-bit for double precision and ?79-bit for double extended precision (I believe x86 uses 80 bit for double extended).

IIRC the main reason for 64-bit slowdowns is there is more data to shove through the bus as the binaries are larger.

Also, it's worth noting that in most cases (x86, SPARC, PowerPC) the incompatibilities are one way only, i.e. 64-bit CPUs can run 32-bit code fine (and often do it faster) but 32-bit CPUs can't run 64-bit binaries

@Metalheart

The biggest benefit of "native" AMD64 code over x86 code is that you have 16 pretty much general purpose registers to play with, as opposed to x86 where you have 8 registers. Of those 8, 3 have very limited use and the other 5 also have some constraints on how thay can be used (for example, division always puts the quotient in EAX and the remainder in EDX). The larger number of registers (and the fact that they're mostly all purpose) was one of the huge advantages of 68K over x86 back in the day.

@NutsAboutAmiga

Quote:

64bit is twice as large as 32bit, so if you write program and decides use 64bit to hold a counter value that will contain a value from 0-255 you wasting 7 bytes of memory, and your RAM buss will need to deal whit it (slower more bloated applications, because the wasted ram will need to swapped out to disk, when your physical memory is full)

Not really. Amd64 has instructions that work with 8, 16, 32 and 64 bit words, precisely to prevent that problem. Also, the amd64 instruction set uses some of the tricks that x86 used in the move from 16 to 32 bit, in order to provide very good code density. Some instructions are larger (those that use pointers from memory to implement things like jump tables), but the vast majority of code does not do that. Since you also have twice as many registers, the program does not need to juggle values as much, which usually more than makes up for the few larger instructions. This means that a program compiled for 32 bit and for 64 bit will be roughly the same size for both versions, and in fact sometimes the 64 bit version will be smaller than the 32 bit version.

64 bit code is also not slower than 32 bit code, at least not on the amd64 platform (in fact, the ability to work with 8 bytes at a time can make some types of program a lot faster). Where did you hear that?

Last edited by CodeSmith on 12-Oct-2007 at 06:58 AM.

Quote:

Also, the amd64 instruction set uses some of the tricks that x86 used in the move from 16 to 32 bit, in order to provide very good code density. Some instructions are larger (those that use pointers from memory to implement things like jump tables), but the vast majority of code does not do that.

Moreover, x86_64 introduced program-counter relative addressing, which all of you know from both m68k and PPC. It reduces the code size (access to data which is +-2GB away from the instruction is better encoded) but also reduces the amount of relocations required at programm start :)

Quote:

This means that a program compiled for 32 bit and for 64 bit will be roughly the same size for both versions

Small example - the size of .text section of muimaster.library. The 32-bit version: 332 Kilobytes. The 64-bit version: 337 Kilobytes.

Quote:

in fact, the ability to work with 8 bytes at a time can make some types of program a lot faster

All bit-related operations are almost twice as fast on 64-bit architecture. Independent on the operand size, searching for least significant bit set is one instruction. Another bit-related example: the bit count in 32-bit is done as follows:


ULONG bfcnto(ULONG v)
{
ULONG const w = v - ((v >> 1) & 0x55555555); // temp
ULONG const x = (w & 0x33333333) + ((w >> 2) & 0x33333333); // temp
ULONG const c = ((x + (x >> 4) & 0xF0F0F0F) * 0x1010101) >> 24; // count

return c;
}


Whereas the 64-bit version does only a tiny bit more and is almost twice fast:


ULONG bfcnto(UQUAD v)
{
UQUAD const w = v - ((v >> 1) & 0x5555555555555555ULL);
UQUAD const x = (w & 0x3333333333333333ULL) + ((w >> 2) & 0x3333333333333333ULL);
UQUAD const y = (x & 0x0f0f0f0f0f0f0f0fULL) + ((x >> 4) & 0x0f0f0f0f0f0f0f0fULL);
UQUAD const c = ((y + (y >> 8) & 0x00ff00ff00ff00ffULL) * 0x0101010101010101ULL) >> 56;

return c;
}


Nice, isn't it?