[fbsd_questions] "i386" fbsd_platform vs "amd64" fbsd_platform, on "intel_64_architecture" cpu

Tue Oct 5 22:22:32 UTC 2010

[ note that there is a new question, about half_way down ]

first, i thank you, most sincerely, for the time that you took to type detailed responses.
this is most helpful.

second, let me posit that there exists no "perfect" notation, so,
   i err on the sides of readability and clarity, at the expense of economy
   [ or, rather, my perceptions of these ].
to this end, i do several things.
i connect the components of a multi_word noun_phrase with under_score characters,
   to aid the differentiation of adjectives from nouns.
similarly, i separate the components of "combination" words.
i use doubled under_scores, if a component is under_score__connected.
i use the neutral_double_quote character to repeat, verbatim, the words of another,
   to indicate "odd" word_usage and
   to emphasize differences.
i use commas liberally, to set_off subordinate_clauses and
   to indicate pauses, --but--,
   i do not put a comma before or after a conjunction
   [ except as part of a comma_pair, used with a subordinate_clause ].
i italicize or under_score "word" as "--word--".
outside of prose, i put white_space between tokens [ don't you wish everybody did ? ].
there are other rules [ hmmm ... , i ought to publish these ].
note that i am, in_frequently, in_consistent in my rule_application.

third, i will address your points in_line.
note that my text is delimited by one blank_line above and three blank_lines below.

Dan Nelson wrote:
> In the last episode (Oct 05), spellberg_robert said:
> 
>>well, i looked at questions back to the beginning of august.
>>
>>on aug_09 i found a thread that suggests the following questions.

i have, since, examined subject_lines back to the beginning of june.
i have researched other places, also.

> You might want to just use "i386" and "amd64" instead of making up your own
> terminology ("i_386", "intel_64", "amd_64", etc).

not mine.

"intel_64" and "intel 64" and "intel64" are synonyms for a concept found here:

         http://developer.intel.com/technology/intel64/index.htm

"i_386" and "i386" are synonyms for a concept found, as one example, here:

         ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/8.1

"amd_64" and "amd64" are synonyms for a concept found, as one example, here:

         ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.1

note that the words on the subject_line are spelled "i386" and "amd64",
   for the benefit of those who use freebsd.org's mailing_list__archive search_engine.
note that i have revised the subject_line, in an effort to be clearer, regarding jargon.

> Note that Intel has chips
> that support two competing 64-bit instruction sets: ia64, which is used by
> their Itanium line,

actually, i am aware of this;
   however, just because i did not discuss it does not mean that
   you can assume that i was not thinking about it.
mea culpa.
being explicit is a_good_thing.
[ i don't need to explain the acronym "assume", do i ?
   good.
]

> and amd64, which originated on AMD chips but Intel
> adopted for their 64-bit-capable x86 chips (Xeon, Core etc).  I'll assume
> that any time you say "intel_64" or "amd_64" you really mean amd64,

no.
"intel_64" and "amd64" are as defined, above.
one is a manufacturer's proprietary architecture;
   the other is a freebsd_release_platform that
   runs on several substantially_similar proprietary architectures,
   which belong to different manufacturers.

> since
> nobody uses Itaniums :)

if they used itania in redmond, ... .

>>for a given release of freebsd,
>>
>>   q:    is it that the version labeled "i386" contains only 32_bit
>>           headers and source, which creates the 32_bit version of
>>           freebsd, as well as 32_bit versions of what i write, which will
>>           run as 32_bit code on either i_386, intel_64 or amd_64 ?
> 
> 
> Yes, assuming you have COMPAT_FREEBSD32 in your kernel config (which GENERIC
> has, so most people have it).

i will look into "COMPAT_FREEBSD32";
   i have not built a kernel since "4.early".
i would take out stuff that i did not have installed and, then, it would get bigger.
now, i change hardware so frequently, it is better to include probes for everything.

>>   q:    is it that the version labeled "amd64" contains only 64_bit headers and source,
>>           which creates the 64_bit version of freebsd, as well as 64_bit
>>           versions of what i write, which will run as 64_bit code on the
>>           intel_64 and the amd_64, but, not the i_386 ?
> 
> 
> Yes.

i think we understand one_another here; i could have been clearer.

i was trying to make a distinction between products manufactured by intel_corp, amd_corp and others,
   all_of_which were derived from intel's original 80386 [ released, circa 1985 ],
   whose architecture intel named "ia-32" [ synonyms of "ia32" and "ia_32" ],
   which, mostly, but, not_exactly, used the same machine_code, to produce the same instruction_results
   [ an analogy would be firefox versus "the high_priced spread", regarding html ].
my cpu distinction was between intel's "ia_32" and intel's "intel_64", that is,
   having --only--  8 32_bit registers versus
   having          16 64_bit registers that could be used as such or
                                       that could be used as if it had only the 8 32_bit registers.

in the first line, "amd64" refers to the freebsd_release platform.
in the fourth line, "intel_64" refers to the content of the intel_corp architecture link, above,
   "amd_64" refers to amd_corp's architecture and
   "i_386" refers to intel_corp's "ia_32" architecture, regardless of the chip manufacturer.
these definitions, also, apply to the previous question.

>>   q:    if a "i386" version is installed on an intel_64 platform, then
>>           the pointers are 32_bits_wide, no matter what ?
> 
> 
> Yes.  FreeBSD's models are ILP32 (int, long, pointer are all 32-bit) or LP64
> (int is 32-bit, long and pointer are 64-bit).

understood.

therefore, i conclude that, in the freebsd_universe of 32_bit and 64_bit architectures,
   the "int"  is --always-- 32_bits_wide    and
   the "long" is --always-- pointer_width.
this is a useful rule.

 >---->  wait_a_minute !

         see what i said, below, about the address_size over_ride.

           new_q:    would "ilp32" mean that "long long" is the 64_bit integer_size ?

         no, i do not mean the kloodgy "double integer" "attribute" of gcc.
         i want the native register_set__count of 16 and the native register_set__bit_width of 64,
           when i am using 32_bit pointers.

>>   q:    if i want to produce both 32_bit and 64_bit versions of my
>>           "killer_app", then i need two machines,
>>             one       a 32_bit or          a 64_bit running "i386",
>>             the other             --only-- a 64_bit running "amd64" ?
> 
> 
> Or an amd64 machine with a 32-bit world installed in a subdirectory that you
> can chroot to to do your 32-bit compiles, or a virtual machine running a
> 32-bit world.

i will look into this.
however, my target user_base,
   while, generally, being competent to write application_code [ in c and sh ],
   would not, with few exceptions, be expected to do
   systems_work beyond "sysinstall" and, maybe, some "rc.conf" over_rides.

this is looking, more and more, like a dedicated_purpose__hardware situation.
when in doubt, make things as simple as possible, but, no simpler.

>>   q:    given that i have intel_64 hardware,

here, i --specifically-- meant a cpu manufactured by intel_corp with built_in 16 64_bit registers.
see the intel link, above.

>>           do i need to start acquiring the "amd64" versions of the
>>           releases, rather_than / in_addition_to the "i386" versions ?
> 
> 
> If you have more than 4GB of ram, it would be a good idea.  If you have 4GB
> or less, then 64-bit mode doesn't buy you much, and may cost you performance
> since all your pointers take up twice the space, filling up your L1/L2
> caches twice as fast.

aha !
i hadn't considered the caches [ thank you for that ].
i was concerned with struct sizes and alignments and, to a lesser extent,
   with stack_segment limits.

my current crop has 4_gigs each,
   but, i am already anticipating larger sizes for the next crop.
your point is well_taken.
i want to get started on seeing what the compiler produces, so,
   i'll bite the bullet, a little.

when i was only concerned with 32_bit code [ my "d"_flag == 1 ],
   it was easy enough to use the 0x_66 over_ride to do 16_bit arithmetic;
   all of my pointers were 32_bits_wide.
now, having the register_set, i have an "l"_flag and it will == 1.
i was debating the idea of always using the 0x_67 over_ride to effect 32_bit pointers.
with separate byte_size instructions, 0x_66 and rex.w,
   i have 8_, 16_, 32_ and 64_bit arithmetic.
the design of structures and code becomes intuitively_obvious.
if i did this, i could delay the use of 48_bit pointers until they became necessary.
this has serious advantages.

i have to determine how to make the compiler do this;
   probably, yet_another_command_line_option.

 >---->  this is a continuation of "wait_a_minute", above.
         here is the specific thing i meant in the "ilp32" section, above.
         your mention of the l1 and l2 cpu_caches gives me another reason to
           make the "small" version of my "app" use 32_bit pointers,
           notwithstanding the use of native 64_bit integers.
         i would be --shocked--, if i learned that i could not do this.

         yes, the compiler/assembler is supposed to
           define the segment_descriptor and
           insert the "rex", "66" and "67" instruction_bytes, as appropriate.

see volume one, chapter three, section six, here:

         http://developer.intel.com/products/processor/manuals/index.htm

>>   q:    given that --i-- am committed to 64_bit hardware, perhaps, i
>>           should give up on the "i386" versions of the releases and
>>           require my users to spend us$_300 on 64_bit hardware [ it would
>>           save a large number of conditional_compilation directives;
>>               nudge_nudge, wink_wink, say no more
>>           ] ?
> 
> 
> Or provide source and let the users compile what they need on their own
> machines.  Assuming you code using the appropriate types (size_t, intptr_t,
> etc, or int32_t and int64_t for when you know you need a particular word
> size) instead of assuming that a pointer will fit in an int, your code
> should compile on either 32- or 64-bit machines with no conditional code.
> 
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

i understand where you are going with this and, in general, it is not all that bad of an idea.
however, i have transcended much of the new stuff and have reverted to using only the basics.
rugs have been pulled_out from under me, too many times.

the real problem is that
   the software industry is over_populated with people
   without sufficient discipline to write correct code,
   given that they start with a known, correct algorithm.
i do not mean insufficient_experience; i mean just_plain_sloppy.

example:  there is no need for a "const" key_word.
if you are not supposed to write to something, then do not write to it [ doctor, doctor, ... . ].

what keeps me out of trouble is to define fundamental types and their pointers,
   then using them exclusively, unless i have to cast [ which i do, liberally ].

example:
   typedef                 char  srl__t__c1__t  ,  * srl__t__c1__p  ;    /* this one is --stupid-- */
   typedef    signed       char  srl__t__s1__t  ,  * srl__t__s1__p  ;
   typedef  unsigned       char  srl__t__u1__t  ,  * srl__t__u1__p  ;
   typedef    signed short int   srl__t__s2__t  ,  * srl__t__s2__p  ;
   typedef  unsigned short int   srl__t__u2__t  ,  * srl__t__u2__p  ;    /* and so forth */
//       int or      long int for u4 and s4 , whatever it takes.
//  long int or long long int for u8 and s8 , whatever it takes.

then i define variables, with the type as part of the name:

   #define                  SRL__EQU__SIZE_ALLOC__STRING_BUFFER__BYTE__U4T       ( ( srl__t__u4__t ) 1024 )

   srl__t__u1__t            srl__v__buffer__read__a_u1t
                            [ SRL__EQU__SIZE_ALLOC__STRING_BUFFER__U4T
                            ]                                                  ;    // the storage, with a "base" name.

   srl__t__u1__p            srl__v__scan__read__u1p                            ;    // a scanning pointer, for tokens.

one of my pet_peeves is that i can not remember other people's ideas of the appropriate default;
    int_t   vs  uint_t     and
   ssize_t  vs   size_t  , so, i define both kinds, explicitly, and stop looking things up.

i am starting to digress, but, you get the idea [ one day, i should publish this, also ].

it looks more and more like i am going to have two sets of hardware and software,
   with ethernet cables.
i need the "amd64" fbsd_release for the 64_bit registers, but, that
   i should not use this to build a 32_bit version of my "app".
i conclude that i will need the "i386" fbsd_release to accomplish that objective.
i suspect that i can get_away_with a single header, with macroes and typedefs, to keep things straight.
fortunately, hardware is astoundingly cheap [ who says that global_economic_depression is a_bad_thing ? ].

i have added to my "do_list" to get the amd_corp manuals on their 64_bit implementation.
when i find the time, i will compare and contrast with that of intel.

again, i thank you.
if you or anyone_else has corrections, elaborations, complaints or great_thoughts, do not hesitate to write;
   in particular, about 32_bit pointers in 64_bit mode.

rob