Date: Tue, 05 Oct 2010 22:22:29 +0100 From: spellberg_robert <emailrob@emailrob.com> To: Dan Nelson <dnelson@allantgroup.com>, fbsd_questions <freebsd-questions@freebsd.org> Subject: Re: [fbsd_questions] "i386" fbsd_platform vs "amd64" fbsd_platform, on "intel_64_architecture" cpu Message-ID: <4CAB9715.2080303@emailrob.com> References: <4CAA3030.3090001@emailrob.com> <AANLkTintm_XubwCCRNJci99Y4M6nwbFr=oiKqBw2%2Ba9M@mail.gmail.com> <4CAA3CFE.1060609@emailrob.com> <AANLkTi=e8cBqd6Z=zxOxpMZm_RD=-RODupzprK843=qF@mail.gmail.com> <20101004225757.GK40148@dan.emsphone.com> <4CAA654B.7040409@emailrob.com> <20101005034150.GL40148@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CAB9715.2080303>