Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 20 Oct 2014, 04:44
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
pUPnGO - 6Mb ISO - Basic Building Block Puplet
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 56 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 54, 55, 56, 57, 58 Next
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Thu 19 Dec 2013, 02:54    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Thu 19 Dec 2013, 04:24    Post subject:  

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

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Thu 19 Dec 2013, 11:56    Post subject:  

Thank you so much guys! I think I got it now Smile
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Thu 19 Dec 2013, 14:42    Post subject:  

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
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Thu 19 Dec 2013, 16:24    Post subject:  

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...
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Fri 20 Dec 2013, 08:14    Post subject:  

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.
Back to top
View user's profile Send private message 
Keef


Joined: 20 Dec 2007
Posts: 633
Location: Staffordshire

PostPosted: Fri 20 Dec 2013, 19:37    Post subject:  

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




Obscure music reference explained here
Back to top
View user's profile Send private message 
PANZERKOPF

Joined: 16 Dec 2009
Posts: 280
Location: Earth

PostPosted: Sat 21 Dec 2013, 10:19    Post subject:  

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.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Sat 21 Dec 2013, 10:40    Post subject:  

"Pup Will Eat Itself" -except that Pup has never first been itself.
Back to top
View user's profile Send private message 
starhawk

Joined: 22 Nov 2010
Posts: 2937
Location: Everybody knows this is nowhere...

PostPosted: Sat 21 Dec 2013, 11:50    Post subject:  

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 Razz

_________________
Loving X-Slacko 2.1!
Custom Build: HP MOCA-AR + Core2Duo T7200 + 4gb RAM + 256gb SSD
...just needs a pretty case Wink
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Sat 21 Dec 2013, 12:55    Post subject:  

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
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Sat 21 Dec 2013, 13:53    Post subject:  

He He, that looks like one of those weighted sleds that they use at the Tractor Pulls!
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sat 21 Dec 2013, 16:14    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
wanderer

Joined: 20 Oct 2007
Posts: 230

PostPosted: Sun 22 Dec 2013, 13:22    Post subject:  

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
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Sun 22 Dec 2013, 14:05    Post subject:  

Quote:
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, 06:07; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 56 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 54, 55, 56, 57, 58 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 2.7630s ][ Queries: 12 (2.6680s) ][ GZIP on ]