pUPnGO - 6Mb ISO - Basic Building Block Puplet

A home for all kinds of Puppy related projects
Message
Author
goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#821 Post by goingnuts »

Might be a stupid question - if such exist...but I have been wondering why it is so important with Puppy to be build for other than i486? Is speed/features using i586/i686/64bit really recognizable?

I run AMD Athlon 64/3000+ with 1Gb ram and have no issues with speed/features - even though I am stuck in P412. I even build all stuff for pupngo with -mtune=i386...

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#822 Post by starhawk »

techno, goingnuts, et al., pardon the n00b question, but why can't a new kernel be compiled for i486? Are the 3 series kernels totally incompatible with that processor?

(I don't know a thing about kernel level stuff, so please be gentle :shock: )

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#823 Post by technosaurus »

starhawk wrote:techno, goingnuts, et al., pardon the n00b question, but why can't a new kernel be compiled for i486? Are the 3 series kernels totally incompatible with that processor?

(I don't know a thing about kernel level stuff, so please be gentle :shock: )
486 is possible but pointless, even dillo-0.8x runs slowly on these systems that are now 20+yrs old and likely close to component failure. AFAIK there is only 1 manufacturer still making i486 (the vortex86sx) and the price is not better than other things on the market (they even make a 586 with mmx). If some chinese firm starts mass producing a high speed, SMP 486 in bulk due to patent expiration this logic would change, but for now the best option is i586+mmx since the rest of the low end CPUs (via, vortex*MX, cyrix, geode,...) in current production and the mainstream CPUs produced over the last 20 years (PentiumMMX+, amd-k7+,...) will perform best with this configuration.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#824 Post by amigo »

'-mtune=i386' is superfluous because glibc doesn't support i386 since 10 years ago.
The jump from i386 to i486 brings the most significant performance benefits for any single jump in kernel arch. i486 is still the best arch to choose if you want to support really old hardware -I'm thinking particularly of geode processors. My current KISS-linux is using i586 which actually is not a good choice. Historically, i586 has had less use and certain combinations of glibc/gcc/binutils will not work for i586 -whereas they work(ed) fine for i486 or i686.

I'm going to be upgrading KISS soon and am going to change to i686 -I figure that there are so few Pentium I's out there that they can be ignored. i686 means a minimum of Pentium II which still offers a way-back reach. And, I still use non-SMP kernel configuration and non-SMP kernel headers for glibc. I figure that SMPÜAE belongs to 64-bit systems. Yes, there are smp processors which are not 64-bit, but even though an SMP-enabled kernel will run on *some* non-SMP machines, they will not run on all of them. So, you'd still need both smp and non-smp kernels for 32-bit systems.

3-series kernels can still be compiled for 486, but 386 is no longer supported at all. And since i586 is an 'iffy' choice, one should either stick with i486 or jump to i686.

All of these choices are made much easier when working with a truly modular system where things are thought-out and built with flexibility in mind. And having a good system for building packages makes it possible to maintain more than one package tree for different arches from the same sources and build scripts.

Looking forward, then 64-bit is the only way to go. But, if wanting to look back at the same time, then it is time to have builds of multiple arches. Of course, you have that now with fatdog & Co., but the common build system is not there. A rethink is needed because trying to build robust systems by robbing packages from here and there is simply not maintainable.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#825 Post by goingnuts »

technosaurus & amigo: Thanks for the detailed explanations! Still not sure if I now know if there are any advantage by compiling applications with i486 versus i686 in respect to size/speed/features when running Puppy. It seems that if we use i486 we make sure they will run with old cpu as well as new cpu. If i686 is chosen only "newer" cpu will be supported.

For the kernel version my experience is that P216 will run (boot) on pentium1 but P412 will not. Is it possible to compile P412 kernel to run (boot) on pentium1 as well or is there a clear break at a certain kernel number where pentium1 was excluded? Could explain the need for the P412retro version...

I have 2 old notebooks which refuse to boot P412 based pupngo but they happily boots P216 based. P216 & P412 can share squashfs if version 3.0 is used. It only have minor influence on the squashfs-file size as shown below testing compressing the main-sfs files of Puppy-3.00:

org_P300_main.sfs unpacked: 217M
squashfs3.0 (gzip): 77M
squashfs3.1 (gzip): 76M
squashfs4.0 (gzip): 76M
squashfs4.2 (gzip): 76M
squashfs4.2 (xz): 64M

If possible this opens for a shared core-pupngo-sfs for kernel P216 & P412 as well as shared application squashfs-files. Might even open for a shared initrd. Could mean a quite compact 2-kernel version might be possible...

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#826 Post by amigo »

If used alone, mtune sets both the upper and lower limit of hardware support. To have things support a range of hardware, you should use -march as well, like this:
-march=i486 -mtune=i686
This means that i486 will be supported, but when used on a newer machines, then features up to i686 will also be supported. In theory, you could use an even newer arch for mtune, but this is probably not recommended -no one else does it that way.
for my system, I use -march=i586 -mtune=i686, but this is done for everything on the system -and the kernels are compiled with i586 as the arch.
It never makes any sense to compile software for use on an arch which is less than that supported by glibc. If you have a glibc compiled for i686, then the system(OS) will not work on a lesser system -even if you use a kernel which is compiled for i486, for example.

Also, the , --build=??, --host=?? and --target=?? directives are meant to help configure routines find a *toolchain* -they don'T directly enable any features at all. Using them keeps confiure from having to guess and possibly guess wrong about which toolchain to use. Also, the build directive tells configure which machine the software is being compiled on. The host directive tells configure which machine the software will be running on. Of course, when compiling natively, build will be equal to host. When compiling natively, none of these directives are needed (target only ever makes sense in the context of building a compiler or binutils.)

As I mentioned before, the biggest single jump in hardware support is that from i386 to i486. Later jumps provide less benefits for each jump.

To build a system, one should decide from the outset what should be the minimum system to supprt and then use the appropriate (and same) flags for compiling *everything*. Repeating, the flags used to compile glibc will set the lower limit for everything (except for anything which is statically compiled). None of these limit the upper range of what the system can run on. When you use march=i486 -mtune=i686, then the system will still run on i786- it just won't use any of the extra features available for i786.

Finally, 99% of all software is completely indifferent to these directives. The exceptions are things like video players, sound and video editing programs and high-performance libs like boost. Some of these will detect and use features automatically, but most require that options be specified. For instance, to use SSE, a lib or program will provide the --enable-sse option to configure. Some things, like mplayer, will try to detect which kernel is being used and whether such hardware features are available. In such cases, you'll want to definitely specify the hardware level to support. Otherwise, the software will be compiled to support the machine on which it is being built. For instance, if you don't turn off automatic CPU-detection when building mplayer, then it will pick up that you are building on an i786 machine and only support that arch -instead of your bottom limit of i486 or whatever.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#827 Post by technosaurus »

486 is the mimimum, there are a couple of non-FPU boards we don't support (vortex86SX ... any 486SX processors for that matter)
586 is not a significant jump as far as instructions only cmpxchg (it was mostly architectural improvement)
586mmx _is_ a significant jump and is almost required to get decent video playback
686 adds cmov which is 1)technically wrong 2)not widely supported 3)not very useful. See Linus's comments on the subject

Current CPUs should work with 586mmx (including the vortex86MX in Barry's gecko) all the way back to 2nd gen pentiums and amd k6 circa 1997 ... so if we want to support 20+ yr old computers and the vortex86DX, then we would need to do 486 for a few more years otherwise I am all for 586mmx
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#828 Post by goingnuts »

Thank you so much guys! I think I got it now :)

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#829 Post by amigo »

One more detail I didn't fill in. When using --build=??, --host=?? --target=?? configure is expecting host-triplet style input. In other words they should be valid targets, like i486-slackware-linux or -i486-t2-linux. You can find the (build) triplet for your gcc with the command:
gcc -dumpversion

In src2pkg I have an option which lets you pass build&Co. when desired. But, since very few sources need or use this, it is not used by default. Slackware's SlackBuild build scripts always pass the option, but in a different way. Instead of
"--build=i486-slackware-linux, --host=i486-slackware-linux"
a single option is passed at the end of other options like tghis:
"i486-slackware-linux"
This is interpreted to mean --host=i486-slackware-linux, but it also triggers warnings about improper use of --host=??.

In any case, --build is the one you'd only need to specify when cross-compiling or using an alternate compiler. Otherwise the configure system will simply find your compiler anyway.

To make clear the meanings of build, host and target, it's helpful to consider (strangely) the most complex cross-build -called the canadian cross. For a canadian-cross build, host and target are all different. Consider this case:
I have an ix86 machine which I am using to build stuff with. But, I have an old PPC iMac which I wish to use build binaries for an ARM system. I need to build a compiuler which runs on PPC, but produces machine code for an ARM. And I need to build the compiler on my ix86 machine beacuse the PPC machine has no compiler. In this case, I would configure gcc using:
--build=i486-slackware-linux --host=ppc-slackware-linux --target=arm-slackware-linux

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#830 Post by technosaurus »

amigo wrote:I have an ix86 machine which I am using to build stuff with. But, I have an old PPC iMac which I wish to use build binaries for an ARM system. I need to build a compiuler which runs on PPC, but produces machine code for an ARM. And I need to build the compiler on my ix86 machine beacuse the PPC machine has no compiler. In this case, I would configure gcc using:
--build=i486-slackware-linux --host=ppc-slackware-linux --target=arm-slackware-linux
So you are the one they invented canadian cross compilation for...
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#831 Post by amigo »

Well, no. But I personally invented the cannibal-cross. That's where you take an existing system and hijack it and then slowly consume it until the whole system is yours.

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#832 Post by Keef »

Great idea for the next CE: "Pup Will Eat Itself".




Obscure music reference explained here

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#833 Post by PANZERKOPF »

amigo wrote:' i686 means a minimum of Pentium II
IMHO i686 means a minimum of Pentium Pro.
It was first in i686 family. Next was Pentium II, then Pentium III etc..
SUUM CUIQUE.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#834 Post by amigo »

"Pup Will Eat Itself" -except that Pup has never first been itself.

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#835 Post by starhawk »

PANZERKOPF wrote:
amigo wrote:' i686 means a minimum of Pentium II
IMHO i686 means a minimum of Pentium Pro.
It was first in i686 family. Next was Pentium II, then Pentium III etc..
This is correct, according to Wikipedia as well. Most people are confused because they've never heard of a Pentium Pro -- it was a spectacular flop! Too expensive for what little improvement it had (on-the-chip cache in a time when that drove up the production costs to insane levels, and therefore drove sales prices up even higher) -- note that performance was not significantly improved really at all -- and it was a bad sell because Intel did it wrong (they marketed it as a server CPU back in the earliest days of such) and IIRC the matching socket (Socket 8, one of the very few rectangular CPU sockets [most are square] in CPU history -- note, not counting DIP sockets in that!) had some electrical issues as well, not unlike Socket 423 (for Willamette Pentium 4's) later on...

A note about Socket 423 and the matching Willamette-core P4's -- I've seen three Socket 423 CPUs (they're long since gone off to recycling, as they're neither functional to me, nor are they particularly pretty) and it looks like Intel's idea was to put the CPU on a carrier board. Probably the issue, therefore, was crosstalk -- above a certain speed of data communication, electromagnetism did its thing and each wire acted like an antenna, transmitting and receiving signals to/from neighboring wires. The Willamette P4's were (in)famous for two other things: producing tremendous amounts of heat, and having very poor performance. Intel actually revived the last-gen P3's (Tualatin, IIRC) and crippled them by sticking half the L2 cache in that they were supposed to get -- and THOSE were better! Intel did that basically to stay alive at the time. Socket 423 and the Willamette P4's were horrible indeed.

But I'm rambling so I'll shut up now :P

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#836 Post by goingnuts »

My web server is a Compaq Deskpro 4000, 200mhz Pentium Pro - and it identify itself as i686.
I own a Compaq Proliant 2500 which can hold 2xPentium Pro processors - but I only have one in it. Never really used it - sounds like a minor jet when running - and quite critical on which OS it allow me to boot. Should have got rid of it many years ago - but it looks like new - and the size and weight is impressing...found an image

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#837 Post by amigo »

He He, that looks like one of those weighted sleds that they use at the Tractor Pulls!

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#838 Post by technosaurus »

Pentium Pro: 686 with CMOV, without mmx and max clock of 200Mhz
Pentium MMX: 586 without CMOV, with mmx and max clock of 233Mhz
AMD k6: 586 without CMOV, with mmx and max clock of 300Mhz
(all of those are out of production for 10+ years)

Vortex86MX: 586 without CMOV. with mmx and max clock of 1000Mhz
AMD geode GX2: 686* without CMOV, with mmx and max clock of 400Mhz
Via C3: 686* without CMOV, with mmx and max clock of 1400Mhz
Via C7: 686* without CMOV, with mmx and max clock of 2000Mhz
(these are still in production)

*CMOV is _supposed_ to be optional in 686 it theory, but in practice it is not. OTOH mmx is not required to be considered 686, but is more useful and more prevalent but requires additional -mmmx CFLAG to produce native mmx code. This is why I suggest 586MMX as a sane default.
wikipedia wrote:Code intended for i686 may fail due to the lack of a Conditional Move (CMOV) instruction. This is an instruction that combines the effect of a conditional branch and a move instruction. Compilers asked to optimize code for a more advanced CPU (for example the GNU Compiler with its -march=i686 option) generate code that uses CMOV. Linux systems intended for to run on i686 are generally not runnable on Vortex86 because the GNU C Library, when built for i686, uses a CMOV instruction in its assembly language strcmp function, which its dynamic loader (ld.so) uses. Hence, no program that uses shared libraries can even start up.

Technically, CMOV is optional in the i686 architecture. But Intel's i686 product, the Pentium Pro, had it, and consequently things that generate code typically consider CMOV to be available when you ask them to generate code for i686.
Its amazing how cool went from the giant frankenstein cases to an octocore arm that fits in an altoid tin. I finally recycled my cases about a year ago.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#839 Post by wanderer »

sorry to ask
but i have been reading the pupngo thread and it is hard going for me

is there a summary of the development of pupngo so i can have an overview of the process and what is the current state and last iso of pupnogo

anyone who has the patience to answer will be much appreciated

wanderer

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#840 Post by goingnuts »

is there a summary of the development of pupngo so i can have an overview of the process and what is the current state and last iso of pupnogo
Best summary still the one on page 1. Latest pupngo iso is from summer 2011 although latest modifications can be found in the pupngo2012 thread.
There are no deadlines for - or targeted new release - although I have worked towards a 2013 version. That wont come. Now I work towards a 2014 version. Focus shifts - as I would like to bring some improvements rather than just a rebuild/re-master. The 2011 (and/or the 2012) are quite mature in my eyes. With little effort it can be remastered to run most official Puppys main sfs-file - and a range of other Distros as well - not to say that is a good purpose in it self - more as a statement of the level of maturity I think it has.

You can convert an official Puppys main sfs-file to squashfs3.0 or 3.1 and after boot of pupngo run the otf_sfs_loader.sh to add the squashfs-file to the aufs branch. Run xwin and there you go. You can fine tune by removing specific modules or applications already provided by pupngo to reduce size or customize the build.

Same procedure with other Distros - make a squashfs-fielsystem of all the files - and use otf_sfs_loader.sh to run them.

One of the unique strengths is still the static linking of all binaries in the core pupngo in combination with the full (I think...) toolset from the real Puppy (boot from whatever, save to whatever, various cli setting wizards etc).
Last edited by goingnuts on Mon 23 Dec 2013, 10:07, edited 2 times in total.

Post Reply