Slashdot Mirror

Passing in registers is not a standard C parameter passing method

There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.

If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.

Must of what you said is true and fair, but i call bullshit on this:

Debian was one of the reasons that AMD64 support is as good as it is under Linux. The Redhat, gentoo, and slackware users that use the 64bit versions are benefiting from Debian getting their distribution to run on 64 bit platforms for years.

FWIK it was Andi Kleen from SuSE to port linux's kernel on AMD64. Quick googling:

http://www.x86-64.org/pipermail/announce/2001-June/000020.html

No, I'm sure he meant what he said. It's very common to call it that.
Used here for example...
Although AMD renamed it
So did Intel

WTF?

1. You're gonna need multiple Linux flavors and versions from multiple sources that specialized in these platforms.
   
   • ALPHA
     
   • ARM
     
   • I686
     
   • IA64
     
   • M68K
     
   • PowerPC PenguiPPC Denx
     
   • MIPS
     
   • S390
     
   • SuperH
     
   • UltraSPARC
     
   • X86_64
     
   
   
2. To determine which versions of crosstool (compiler, linkers, debugger), check out The Matrix Guy (Dan Kegel), or more specifically THE MATRIX of workable gcc/g++/ld/gdb.
   
3. To ease your pain of figuring out the "./configure" options, definitely checkout PTXDist. Menuconfig is similar to Linux 'make menuconfig'. PTXDist also help to build a root file system in a jiffy, which in my book, is a PLUS!
   

AMD is well-supported under Linux and supports Linux rather well (though I imagine it's more on one side than the other).

They're not just well-supported, AMD actively works with the community! That's the only reason we have Linux support for the x86-64 processors, not because Intel was being a nice processor overlord or people spent the last decade hacking support: http://www.x86-64.org/

...does it run Lin--ah, just about everything does.

But, does it run Racer --ugh, runs that too...

BUT, does it use x86-64? YES, something it can't do! But then you all knew that.

But I am the author of the entire word processor program. The spellchecker is only combined with it.

I don't see a practical problem here. If you put the copylefted spellchecker in a separate process, and you have it talk to your proprietary word processor over a pipe or a local socket and make sure to document the protocol, then you have implemented enough separation between your work and the spellchecker author's work to satisfy the letter of the GNU GPL.

If it wasn't then you couldn't run anything non-GPL at all under Linux because every program must link to the int80h API that the kernel provides for system services.

The Linux kernel license is GNU GPL version 2 with an express exemption for applications that access the kernel through syscalls. Courts haven't stated whether this exemption is required in order to link Linux headers against a proprietary app.

C:\Program Files\NTDDK\4074\bin\win64\x86\amd64>cl
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.31008.15 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

"Linux wil run on most, if not all desktop computers currently running Windows."

In fact, Linux runs on about 23 additional architectures that Microsoft can't even remotely support with their most-flexible embedded target.

• Diverse PDA / embedded / microcontroller / router devices:
  • Advanced RISC Machines, Ltd. ARM family (StrongARM SA-1110, XScale, ARM6, ARM7, ARM2, ARM250, ARM3i, ARM610, ARM710, ARM720T, and ARM920T)
  • Analog Devices, Inc.'s Blackfin DSP
  • Axis Communications ETRAX series ("CRIS" = Code Reduced Instruction Set RISC architecture)
  • Elan SC520 and SC300
  • Fujitsu FR-V
  • Hitachi H8 series
  • Intel i960
  • Intel IA32-compatibles (Cyrix MediaGX, STMicroelectronics STPC, ZF Micro ZFx86)
  • Matsushita AM3x
  • MIPS-compatibles (Toshiba TMPRxxxx / TXnnnn, NEC VR series, Realtek 8181)
  • Motorola 680x0-based machines (Motorola VMEbus boards, ISICAD Prisma machines, and Motorola Dragonball & ColdFire CPUs, and Cisco 2500/3000/4000 series routers)
  • Motorola embedded PowerPC (including MPC / PowerQUICC I, II, III families)
  • NEC V850E
  • Renesas Technology (formerly Hitachi) SH3/SH4 (SuperH: link1 link2)
  • Samsung CalmRISC
  • Texas Instruments's DM64x and C54x DSP families
• Intel 8086 / 80286 .
• Intel IA32 family: i386, i486, Pentium, Pentium Pro, Pentium II, Pentium III, Xeon, and Pentium IV processors, as well as IA32 clones from AMD, Cyrix, VIA, IDT, Winchip, NexGen, Transmeta, VIA C3 Ezra "CentaurHauls", and others.
• Intel/HP IA64: Trillian/Itanium/Itanium2
• AMD x86-64 Hammer family (including AMD Opteron)
• Motorola 68020-68040 series (with MMU): m68k Mac, Amiga, Atari ST/TT/Medusa/Falcon, HP/Apollo Domain, HP9000/300, sun3, and Sinclair Q40.
• Motorola/IBM PowerPC family: Most PowerMac (including G3/G4/G5) / CHRP / PReP / POP, Amiga PowerUP System, and IBM PPC64 (AS/400, RS/6000).
• MIPS

I agree, AMD64 has nothing to do with intel x86 and anybody who says it does must be able to read domain names. Or are you saying that AMD64 doesn't just support and extend the x86 instruction set?

Though Xeon-Nocona has been available for more than a month it seems there there are no substantial reports on 64-bit performance of Nocona. Is there anyone here who can report anything about the 64-bit performance of Nocona?

What's telling is that to gain marketshare, AMD decided to rename x86-64 to AMD64. See e.g. what happened to x86-64.org

Read on. There is specific support for the NX flag on pages. If you boot with noexec=on, then stack/heap/data is automatically protected. If the page fault handler sees your thread because of an NX flag violation, the process is killed.
Caveats: you can't mprotect it back to execute status, and it breaks some software, especially Mozilla/Java/Ada (just like exec-shield...)

Seems it's what's happening now. http://www.x86-64.org/

As you can tell by looking here SuSE 9.0 x86-64 Free FTP Install and following the appropriate links (when they're not overloaded).

But this is a 64bit CD!

I've had the amd64 (nee x86-64) manuals that AMD is giving away for free on x86-64.org for a while now. I've been waiting for the Opteron and the Athlon64 with anticipation. And part of the deal with amd64 is that, while AMD was defining a new x86-ish ISA, they made some other changes -- like doubling the number of general purpose registers as well as the number of registers available for MMX and SSE.

But these extra registers are only available when using the new amd64 ISA -- i.e. when executing 64 bit code. We've seen lots of benchmarks and tests with the introduction of the Athlon64 running 32 bit windows, but next to none of the amd64 architecture in 64 bit mode.

But this CD boots the amd64 port of Linux, capable of using all 16 GPRs. And it reads like the America's Army version on the CD was compiled 64 bit too -- so it has access to 16 GPRs, 16 MMX and 16 XMM registers instead of the 8 available to standard x86.

It's the first 64bit game available for the Opteron and Athlon64! Somebody needs to go get this CD and benchmark it next to a 32bit x86 version of America's Army. Anyone, anyone?

Check out AMD64 for upcoming ports of open source projects to the AMD64 platform.

"Programs" such as FreeBSD, Linux, or Windows 2003?

"Programs" such as FreeBSD, Linux, or Windows 2003?

Most stack buffer overrun problems (Blaster bug, etc) are possible because the stack is executable. Other systems, such as VMS on Alpha don't have executable stacks, making this kind of exploits very difficult to do.

At least, the problem seems to have been fixed in the x86-64 hardware, but the operating systems need to take advantage of it. See here.

So when will we see M$ take advantage of good simple security features in the hardware instead of trying to invent new fantastic schemes (Palladium)? Why wasn't buffer overflow attacks fixed 5-10 years ago? I'm not sure if earlier x86 chips allowed non-executable stacks, but if M$ were serious about security, they could certainy have requested that feature from Intel. It's not rocket science.

> Eh, I wouldn't say that GCC is "worthless", it's just that its worth lies in an
> area that has nothing to do with high-performance computing. Or even > mid-performance computing. :)

GCC is really fast.
Look at some SPEC_FP numbers:
(1) http://www.spec.org/cpu2000/results/res2003q3/cpu2 000-20030728-02428.html and
(2) http://www.spec.org/cpu2000/results/res2003q3/cpu2 000-20030728-02417.html

The c++ benchmarks (177.mesa,179.art,183.equake,188.ammp) were compiled with ICC (1) and gcc (2).

At two out of those four benchmarks (50%), GCC 3.3 is FASTER than the best Intel Compiler.

At least for Opteron (and Athlon) GCC is really good. Opteron with GCC and PGI Fortran compiler is excellent suited for High-Performance-Computing.

A big Thanks to the SuSE team for porting GCC to AMD64 and doing some usefull optimizations. http://www.x86-64.org/contributors/gcc

Wasn't there an x86-64 emulator?

Why hmm yes indeed there is.

--TRR

Well the fact that it's totally untrue might have something to do with it.

Who's following who ?

July 2001:Linux supports Opteron

You tell me!

I'm a little concerned that this may lead to no x86-64 (Opteron, Althon64) support from RedHat. :(

HP co-owns the IP for Itanium with Intel, so they have a vested interest in seeing Itanium get lots of support, and AMD x86-64 get none. RedHat has already announced Itanium versions of Advanced Server, but AFAIK, has been silent on the x86-64 front.

SuSE has announced long ago that they'd release x86-64 versions of their distro to coincide with Opteron's release, and they seem to be actively involved with that process.

Am I being paranoid here? Or does it look like RH might not support the most cost-effective 64bit platform going? Not all of us have deep pockets for I2. :(

Don
my smug mug is on smugmug ... is yours?

The guys doing the Hammer port have been talking to no end about this. Have a look over at www.x86-64.org mailing list archives. There's lots of talk about banning trampolines and such. It sounds like Linux on Hammer will not allow executable stack, but since I'm only an occasional lurker there I can't say for sure. Now if only I could buy one...

On top of that, if an app is not made 64 bit ready, why would you need a CPU that is?

The most important piece of software to get upgraded to 64 bit code is not actually an application, but rather the OS kernel you are using. AFAIK the x86-64 architecture is so nicely designed that a 64 bit OS can run both old 32 bit programs and 64 bit programs in a multitasking environment. And even 32 bit applications can get a little benefit from the change by getting the OS outside the 32 bit address range. Thus they can get access to 4GB of address space compared to the 2 or 3GB they would usually have.

A lot more applications will benefit from a recompilation, which might not even require a change of the source code. There are places where 64 bit calculations are already needed on the current 32 bit architectures. There might not be a lot of people knowing it, but in fact we have had the need for 64 bit architectures for many years. I'm looking forward for the new AMD chips.

It's nice that AMD are benefitting from open source developers such as those as http://www.x86-64.org
But keep in mind that AMD have stepped forward (with Intel) and said they will be planting DRM features in their products to satisfy M$'s trusted computing push. And while initially you will be able to turn them off, soon the US and their states such as England and Australia will pass laws to make such consumer disobedience illegal.

Windows XP and Office XP run on the opteron. There was also an article on slashdot a while back about it. Linux ports are definitely in progress, but I don't know if there's anything solid running on 64 bit x86 machines right now.

it seems like this would require a change in how processes are handled in hammer mp systems

There may be a need to tune this specifically to Hammer/Opteron though (and even this could have been done already - need to look again at x86-64 port)

I would like to see one of these give a specFp result

I bet that it could cane IA64 in the specInt but the real test would be floating point and to do IEEE754 properly you need 64 bit otherwise you end up emulating it

now we have of the true 64 bit microproessor's

Sun Microsystems - Processors which are a Sparc

PA-risc which is MIPS like

and MIPS64 which I like alot

of the ports linux to 64bit for linux HPPA and the oldie but goodie linux Alpha and linux sprac64 of course not forgeting linux for IA64 but unfortunately the linux for MIPS is not 64bit so if ever their was a challenge as linux is mostly 64bit clean its to do a MIPS64 port

oh and intel wont like to say linux for hammer which is not real 64bit just has some 64bit registers tacked on (but hey you can do fp right ;-)

Why sit around and wait for somebody else to compile the images for you? Use a source based disto dammit, one that grabs the source to your system and then compiles it. As other people commented before, most linux apps are allready 64bit ready. Because most needs to be compileable on MIPS/ALPHA/SPARC platforms.

GCC(and binutils) supports compiling to x86-64 , this is still experimental though. But searching/looking abit in the mailinglist archives @ x86-64.org show that stuff like qt allready are comiling fine, only needing a wee-change in the makefile(Link).I think thats quite impressive, and im willing to bet good money that GCC has production class x86-64 support by the time the processor is actually available to buy.

So, armed with gcc and a version of Gentoo, Linux From Scratch or any other sourcebased disto that supports compiling the entire system from scratch. You will beable to create/compile your very own system, which can be WAY more optimized that anything a vendor does(i cant really see how its possible for a precompiled kernel images cant be optimized to a system).

The the only bad thing about thiese kinda of disto s is that big large packages as x/gnome/openoffice/what-ever takes for ever to compile. But on 64bit processor, who cares =)

History isn't just in the past. AMD's next processor, codenamed the Hammer, will be the first x86-64 instruction set CPU. To kick start projects wishing to make good use of this 64bit extension to x86, AMD developed and made freely (beer) available virtual machine called SimNow over a year before the chip is due to launch.

What I found particularly interesting was that this seemingly hopefull project was taken up so well that Simics thought it prudent to add x86-64 support to thier existing commercial multi-architecture simulator.

The good news in all of this is that Linux and a fair few of the GNU tools are x86-64 ready now, well in advance of any x86-64 chips' release.

Ah, thanks ;)

Found this PDF document to be a very interesting document with tons of info about the Hammer. So intersting that I felt the need to post it here. :)

Regarding registers, it shows that not only has it got 2x "standard"/GPR registers that's 2x wide, but also 2x SSE/SSE2 128-bit registers.

So it seems to total in 16 * 128-bit registers, 16 * 64-bit registers (and 8 * 80-bit regs for floating point ops).

Yeah, and a widened program counter register too. :D

Here's a short run-down of the improvements that really caught my eye this time around.

• Better PPC support (64-bit PowerPC GNU/Linux support in the backend, and altivec support with -maltivec)
• UltraSPARC 64 fully supported
• AMD x86-64 support
• SSE/SSE2/3DNow!/MMX instructions and command-line flags to enable. No C++ compatible intrics for SSE2
• New ports for MMIX, CRIS, and SuperH
• Code profiling

Everyone knows I'm no fan of the GNU project, but GCC3.1 shows that they have a lot going for them. Very exciting guys, I can't wait to see what 3.2 has in store.

--Dan

you are correct. SuSE is doing serious work on getting x86-64 into the linux kernel. if you click the link to x86-64.org, you'll notice that SuSE is the only distribution featured on the front page. when AMD wanted to demonstrate 64-bit linux on its hammer (now opteron) processors, they used SuSE.

SuSE is also qualified for SAP.

i think SuSE has done a really smart thing in getting a good mix of ease of use combined with stability and scalability. easy to use, but not dumbed down. and everything is nicely integrated.

...they'd embrace the upcoming AMD Hammer architecture and build high-end Linux/Hammer workstations and entry- to mid-level servers around them. Kind of a Sun/Linux meets Apple deal: clean product line, not a lot of overlap, well designed, very cool. I say Linux rather than Solaris if only because it's impossible to do Solaris/x86 device drivers for everything, whereas Linux has a decent chance.

Of course, that'd freak out their SPARC people, so they'll never do it. Pity.

Just treat it like a 64 bit chip. You don't ever have to treat it like anything other than a 64 bit chip, if I understand this pdf correctly.

64 bit mode adds the following features:

• 64 bit virtual addresses
• Register extensions through a new prefix (REX):
  • Adds eight GPRs (That's general purpose registers, folks) (R8-R15)
  • Widens GPRs to 64 bits.
  • Adds eight 128-bit Streaming SIMD Extension (SSE) registers (XMM8-XMM15)
• 64-bit instruction pointer (RIP).
• New RIP-relative data addressing mode.
• Flat address space with single code, data, and stack space.

The PDF also says

The default address size is 64-bits, and the default operand size is 32-bits. These defaults can be overridden on an instruction-by-instruction basis by using a new REX prefix, which has been introduced for specifying 64-bit operand size and for the new registers. The mode is enabled by the operating system on an individual code-segment basis."

So in other words, you can just treat it like 64 bit, all the time. You will never need to use any 32 bit code. But you CAN, which is of course the strength, as you well know, but have chosen to disregard.

If you have not gotten tired of my examples yet:

In 64-bit Mode, General Purpose Registers (GPRs) are extended to 64-bits. The 64-bit registers are called RAX, RBX, RCX, RDX, RDI, RSI, RBP, RSP, RIP and RFLAGS. These new 64-bit registers overlay and extend the existing registers. In addition, eight new 64-bit GPRs are added for a total of 16 GPRS. These new GPRs are called R8 through R15.
The register extensions also add eight new streaming SIMD registers for a total of 16 SIMD registers. These new SIMD registers are called XMM8 through XMM15.
Segment registers (ES, DS, FS, GS and SS) are ignored in 64-bit Mode although code segments still exist in 64-bit Mode. The CS is needed to encapsulate the default mode of the processor (16- , 32- or 64-bit mode) as well as the execution privilege level. As noted above, the D bit and L bit are used to specify the default address and operand sizes. The DPL is used for execution privilege checks. Base and limit fields are ignored.
When performing 32-bit operations and the destination register is a GPR, the 32-bit value will be zero-extended into the full 64-bit GPR. 8-bit and 16-bit operations on GPRs preserve all unwritten upper bits. This preserves the 16- and 32-bit semantics for partial-width results. The final step is to simply define a set of instruction prefixes that specify a 64-bit operand size and allow access to the new registers. This is similar to the method used to extend the x86 architecture for other functionality, such as AMD's 3DNow!(TM) technology. With this strategy, AMD makes it possible for platform suppliers, developers, and other users to use existing toolsets, applications, and knowledge, while providing a smooth migration to 64-bit enabled applications as hardware and software support becomes available.

Still worried?

Check out http://www.x86-64.org/. It's AMD's site dedicated to porting Open Source software to x86-64. This includes the Linux kernel.

I think AMD did pretty well with promoting and supporting x86-64. The x86-64 website has soeme decent stuff including emulator, experimental compiler, etc. It was a smart move and got the developers on board early.

You don't need the hardware. There has been an AMD produced emulator for x86-64 available for some time so people could work on ports. See AMD's x86-64 website. Linux (and/or a BSD variant) got ported to x86-64 some time ago - all without hardware. It was a front page story on Slashdot when it was announced.

Take a look for yourself.

Was it thislink?

I believe you've misread. FreeBSD people are working on adapting a x86-64 GCC port that was done by SuSE. AMD does state on the x86-64 website that they are supporting porting work for both Linux, FreeBSD and NetBSD, however.

Is there any way to link 32 bit data with a 32 bit instruction, ala Itanic?

I'd explain, but I can't even understant what you're talking about. :-)

Obviously you're not aware of how the Athlon works, among other things.

Internally, it has many more registers than four. x86 instructions only reference four registers, but internally the Athlon uses it's full set to speed up the code, as well as exploiting several types of parallelism.

For higher level languages, it is even less of an issue. There may be some impact on my Java code as to whether "int" or "long" has faster operations, but I'll guarantee that all my code using "double" will fly. The best part is that I won't even have to recompile! =)

The other thing I'll gain is that all of my dynamic allocations will have much larger memory limits. The virtual memory limit per process for the first Linux port to Hammer is 511 GB.

299,792,458 m/s...not just a good idea, its the law!

Here's the ABI draft

According to this, long is going to be 64 bits.

I don't like that, actually. You can't really avoid problems with programs that make assumptions about data sizes, since you are basically stuck with 64 bit pointers, and thus some data size relationship has to change. But for many that use long to define a 32-bit type, they are suddenly going to get 64-bit types when they don't need it. That has the potential to do things like blow out your cache, which would hurt performance.

For well-behaved programs, there shouldn't be any problem recompiling for 64-bit mode. There are some advantages to doing so, like being able to take advantage of the extra registers. For poorly-behaved programs... Well, just leave them in 32-bit mode, and they'll run just as well as before.

Advanced Micro Devices, Inc. x86-64 Technology White Paper.

Overview of strategy, some technical detail, "Long Mode" explained, nice charts, etc. Nicely done AMD.

The site also has a 64-bit simulator for you favorite 32-bit processor based Linux system.