I've been rummaging around for the past 6 months, since I got my new amd64 box, and i found a lot of people asking about Slack64 (or similar) and very few responses.

So, I shrugged and got my head down. A few days ago, after 6 months of learning, I managed to get a complete bi-arch toolchain into Slackware 10.

gcc: 3.3.4
glibc: 2.3.3
binutils: 2.15 (stock)

X11 wouldn't build straight off, but hey, one step at a time. A whole bunch of the dev tools got repackaged quite fast and seem ok.

Of course today I was tinkering some more and screwed up a step in trying to build a glibc package - it segfaulted and now I need to start again. Still, the hard learning's already been done - just another few hours of tinkering aught to get me back on track.

I can get a bi-arch toolchain running. I can (assuming I don't mess it up like I did today) package it up and redistribute it ...

On to the real issue:
I noticed in many of the SlackBuild scripts on disks 3 & 4 of 10.1 that optimisation flags had the potential to be set for x86_64. Is Patrick tinkering with it himself, perhaps?

I was planning on emailing him, but, I wanted to start somewhere else first to see if anyone could shed some light on the situation regarding x86_64 and slackware.

The questions:
* is anyone working on Slack64 (or similar)?
* how many people have AMD64 chips and would run Slack on it?
* what's the criteria for getting recognised as an official Slackware port?

I've got dozens of other questions, and my housemates have all been driven insane by my rantings about Slack64, so I've been told to wait until I find fellow enthusiasts before I resume

Keep on Slackin'!
- Piete.

An unofficial AMD64 port already exists: Slamd64

Perhaps your efforts would be better directed to help out with that project, rather than trying to start a second AMD64 port?

Hi Piete

I will definitely be playing with this. I need to recompile exactly the things you mentioned, so perhaps you might consider posting your experiences as a starting point for others.

BTW I've noticed some 64bit pkgs appearing on linuxpackages.net.

And packages are beginning to show up in linuxpackages.net

Slamd64 RC1 works very well. It's rough right now, but with a little work, it's running on my laptop.

Fred, the maintainer of Slamd64, actually needs some help. He has RC2 ready to go, but he is still on dialup, so he can't upload it. I've offered to have him mail me the CDs, but he's in the UK and I'm in the US, so that would be slower than uploading over 56K. Anyone here in the UK with a fast upload? Also, he doesn't have a US mirror, so he's looking for FTP servers.

Personally, I'd like to see Pat advertise Slamd64 as a port of Slackware just like with Slack/390.

Ah! slamd64 is precisely what I was looking for! Thanks to cathectic for pointing this out, I don't know why my searches didn't pick this up before.

Phathead, I'll get in contact with him post-haste, since although I may not have an excessively high-speed connection, I have some hosted web space, I live in the UK and I do have 256 up!

Thankyou all!

- Piete.

Is it a bad idea to think about running a biarch toolchain on a stock 10.1 slackware? I've got a number of machines running 10.1, one of which is an athlon, and my preference would be to just run what I have, with the ability to play with some 64-bit apps on the one machine that's capabable of it, rather that running different dists on different machines.

If that's a stupid idea, I guess I'll just move that one to slamd64.

It's impossible to run a 64-bit app in a 32-bit environment, so although you could have a biarch toolchain on Slackware, you couldn't run any of the 64-bit ELFs without a 64-bit kernel ... then if you have a 64-bit kernel, you'll need 64-bit libraries to support it, and then those will be used by 64-bit apps ...

... and oh look, you've made Slamd64 =)

- Piete.

Well, ok, this is probably going to be an amazingly stupid question, but I'll ask anyway: Why will 64-bit apps not run with a 32-bit kernel? I would have thought it would be workable to have 64-bit versions of all the relevant libraries, and have the initialization code pop the processor into 64-bit mode.

Perhaps the issue is that you don't get to set processor mode on the fly, ie it comes up in either 32 or 64-bit, but once you've decided, you're committed?

Is the opposite restriction true as well, ie if I cut over to slamd64, will none of my 32-bit apps run?

A good question, and well put.

To answer that fully will take a long time and will mean digging very deep, but I will paraphrase myself in the interim. I advise you search for more posts by me including the parameter "x86_64", it's a favourite topic of mine =)

A PC architecture is defined by it's instruction set. ix86 is an instruction set that defines the x86 series (i386, i486, i586, i686) of processors. x86_64 is a 64-bit extension to the ix86 instruction set.

The AMD64 processor was built to be able to run this new x86_64 instruction set (actually, I suspect the instruction set was designed to run the processor, but meh), and additionally, they made the hardware able to run standard ix86 instructions (so-called 32-bit instructions).

A kernel is a squidgy layer of software (as in, "code", not physical hardware) that talks to the hardware. It's what makes it possible for me to talk to you via this messageboard without having to flick an awful lot of switches on my processor =D

If you have a 32-bit kernel (that is to say, a kernel compiled for ix86) it will talk to the hardware with 32-bit instructions. It has no understanding of these 64-bit instructions. The hardware just reads the instructions as 32-bit, because it can do that. It's a native conversion, as far as the kernel is concerned.

When you compile a 64-bit kernel, the kernel now has access to the 64-bit instructions (the x86_64 instruction set) and part of the kernel can be enabled to parse the 32-bit instructions.

So, back to the original question. Why can't we run 64-bit apps under a 32-bit kernel?

In short: The kernel doesn't understand the instructions.

Why?

I have no idea. We are now well beyond my understanding of the kernel, but I'm fairly sure if it could be programmed to run in 32-bit mode, but use 64-bit instructions it would've been done already!

I hope that answers some of your questions regarding "why!", and I urge you to run those searches if the topic interests you - I quoted a really wonderful Ars Technica article about what exactly makes the x86_64 at a hardware level, but I can't seem to find my bookmark of it, now.

As to your other question:

Not at all! As I've mentioned, there is a tickbox in the kernel config that allows you to run 32-bit binary apps. Slamd64 is enabled as a bi-arch install (including a bi-arch toolchain and 32-bit compatibility libaries), much like SuSE and Fedora.

I hope to see you on the slamd64 forums soon =D
- Piete.

Ok, I'll have to take your word for it. Other OS's I've dealt with for multi-modal processors have dealt with this issue by using the app/kernel boundary as a common place to put the processor back into whatever the "standard" mode was for the kernel; I assumed that the same sort of strategy would work here, but it sounds like it's not that easy.

Another wizardly bud of mine believes the issue boils down to the memory management not working (without extra hacking) when the kernel has shorter pointers than the app; I guess I'd believe that theory too.
Sounds like you will be, shortly

One last question, if you will: Anybody out there set up a machine for dual-boot slamd64 vs plain slack? It's clear that I'm going the slamd route on this machine, but I'd prefer to hedge my bets (it's my main server, and I'd like to avoid excess downtime; my wife would kill me ) so would like to install slamd with the option of booting back into 32-bit mode if I encounter problems. Any hints appreciated.

I've always said the linux community was terrific about helping each other out, and you're just confirming my theory. Thanks!