Alpha Linux
John Richardson
mail?
thanks
John Richardson
jric...@cs.uml.edu
bali...@maddog.async.vt.edu
: Can whomever is working on the Alpha port please send me some
: mail?
Last I heard he hoped to have a kit togther in September.
We just got a DEC3000 Model 300 AXP. I sure hope it runs on it. Will it
support OSF partitions?
Philip
--
Linux: The choice of a GNU generation!
Marc Fraioli
>John Richardson (jric...@cs.uml.edu) wrote:
>: Can whomever is working on the Alpha port please send me some
>: mail?
>
>Last I heard he hoped to have a kit togther in September.
>
>We just got a DEC3000 Model 300 AXP. I sure hope it runs on it. Will it
>support OSF partitions?
>
on the DECpc, aka the DEC 2000 Model 300. This is because it has an
EISA bus, which Linux already supports, whereas all the DEC 3000 model
machines have a TurboChannel bus, which it does not. I suppose someone
could write TurboChannel drivers, and then the Alpha version should
work, but what I had heard sure made it sound like the EISA-bus PC
was the target. Also, TurboChannel drivers are of questionable value,
since DEC is moving away from it towards PCI. Of course, an Alpha/PCI
system should be able to run the Alpha Linux port too...
---
Marc Fraioli | "They couldn't hit an elephant at this dist- "
m...@clark.net | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
Douglas Ambrisko
In article n...@solaris.cc.vt.edu, bali...@maddog.async.vt.edu () writes:
>John Richardson (jric...@cs.uml.edu) wrote:
>: Can whomever is working on the Alpha port please send me some
>: mail?
>
>Last I heard he hoped to have a kit togther in September.
>
>We just got a DEC3000 Model 300 AXP. I sure hope it runs on it. Will it
>support OSF partitions?
>
I think the Linux port, like DEC's NT port to the Alpha, will only run
on the DECpc, aka the DEC 2000 Model 300. This is because it has an
EISA bus, which Linux already supports, whereas all the DEC 3000 model
machines have a TurboChannel bus, which it does not. I suppose someone
could write TurboChannel drivers, and then the Alpha version should
work, but what I had heard sure made it sound like the EISA-bus PC
was the target. Also, TurboChannel drivers are of questionable value,
since DEC is moving away from it towards PCI. Of course, an Alpha/PCI
system should be able to run the Alpha Linux port too...
Although Linux has not been ported to DEC mips machines (to my knowledge),
Mach and netBSD have drivers for TurboChannel devices. However, not knowing
anything about Linux drivers it shouldn't be to hard to massage the code to
linux. Atleast the code is know to work (I booted a Mach 3.0 kernel on a
TurboChannel mips box and it saw everything). The biggest task with the
Alpha is making everything 64 bit clean and this will apply to the EISA
drivers.
BTW I have been using Alpha's for a while and ported a bunch of stuff to
them. It is interesting all the little 32bit assumptions you run into,
but man are the compiles fast!
If anyone needs a alpha tester for TurboChannel Alpha, I could help out.
We have just about every type of Alpha here.
--
In Real Life: Doug Ambrisko o o / \o/
e-mail: ambr...@kpc.com //\ //\ / //
voice: (408)987-5820 /\`\/\`\/\ / /\'\/\
\/ '\/ '\/ / \/ \/
Anton Ertl
|> The biggest task with the
|> Alpha is making everything 64 bit clean and this will apply to the EISA
|> drivers.
Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Peter Holzer
>In article <AMBRISKO.94...@tasha.kpc.com>, ambr...@kpc.com (Douglas Ambrisko) writes:
>|> The biggest task with the
>|> Alpha is making everything 64 bit clean and this will apply to the EISA
>|> drivers.
>Only if Linux on the Alpha will be a 64-bit-OS.
I sure hope it will be. Who wants a 32 bit OS on an Alpha?
>If it will be, I hope
>that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
Then you have to drop either the 16 bit or the 32 bit int type. Both
options may make some people unhappy. The 32 bit int is a reasonable
compromise. It also breaks all those programs which assume that a
pointer and an int are just the same thing, which is a good thing IMHO.
hp
--
_ | h...@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
|_|_) |------------------------------------------------------------------------
| | | It's not what we don't know that gets us into trouble, it's
__/ | what we know that ain't so. -- Will Rogers
Albert D. Cahalan
>|> drivers.
>Only if Linux on the Alpha will be a 64-bit-OS.
I sure hope it will be. Who wants a 32 bit OS on an Alpha?
>If it will be, I hope
>that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
Then you have to drop either the 16 bit or the 32 bit int type. Both
options may make some people unhappy. The 32 bit int is a reasonable
compromise. It also breaks all those programs which assume that a
pointer and an int are just the same thing, which is a good thing IMHO.
Why drop one?
16 bits = short int
32 bits = int
64 bits = long
--
Albert Cahalan
a...@meceng.coe.neu.edu
Andrew Ukrainec
Another observation: at least according to the K&R C specification, short
int, int, and long int are not defined to be any specific bit length, and
can all be equal to same bit length, as a matter of fact. The programmer
who writes expecting short int = 16 bits should know that the code will not
necessarily be portable.
Therefore, there shouldn't be a problem defining
short int = 32 bits
int = 64 bits
long int = 64 bits
or all of them = 64 bits. This makes more sense to me than int = 32 bits.
--
Andrew Ukrainec ukra...@soma.crl.mcmaster.ca
< (*) > / \ < (*) >
Communications Research Laboratory McMaster Univ, Hamilton, Ontario
Peter Holzer
>In article <ADC.94Se...@bach.coe.neu.edu>,
>Albert D. Cahalan <a...@bach.coe.neu.edu> wrote:
[Anton Ertl:]
>> >If it will be, I hope
>> >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
[Peter Holzer:]
>> Then you have to drop either the 16 bit or the 32 bit int type. Both
>> options may make some people unhappy. The 32 bit int is a reasonable
>> compromise. It also breaks all those programs which assume that a
>> pointer and an int are just the same thing, which is a good thing IMHO.
>>
>>Why drop one?
>>16 bits = short int
>>32 bits = int
>>64 bits = long
This is, what OSF/1 does. So `the OSF/1 idiocy' bemoaned by Anton must
be that int is 32 bit instead of 64. If you have 64 bit int and 8 bit
char (I don't think you want to change that) you can have either 16 bit
shorts or 32 bit shorts. You can't have both (unless you invent a new
type like `short short' or `long short'). This means that either the 16
bit or the 32 bit integral type is not accessible from C.
>Another observation: at least according to the K&R C specification, short
>int, int, and long int are not defined to be any specific bit length, and
>can all be equal to same bit length, as a matter of fact. The programmer
>who writes expecting short int = 16 bits should know that the code will not
>necessarily be portable.
>Therefore, there shouldn't be a problem defining
>short int = 32 bits
>int = 64 bits
>long int = 64 bits
>or all of them = 64 bits. This makes more sense to me than int = 32 bits.
No problem as far as standard C goes. There is a problem with existing
software, however. There are lots of places in a Unix kernel where the
existence of a 2-byte integral type is assumed. If you don't have such
a type you will have problems. If you are lucky you can use 32-bit
integers instead and just waste space. If you are unlucky, you will have
to use a struct or an array of two chars instead and rewrite your code
accordingly. I am quite sure the Deccies had a lot of fun by changing
the size of of two types (long and pointer), especially in networking
code.
Steven A. Reisman
: Why drop one?
: 16 bits = short int
: 32 bits = int
: 64 bits = long
128 bits = long long :)
--
Steven A. Reisman
12695 4th St. S. s...@beehive.mn.org
Afton, MN 55001 (612) 436-7125
Steven Youngs
In article <34i2gj$9...@news.tuwien.ac.at>, h...@vmars.tuwien.ac.at (Peter Holzer) writes:
|>Path: ncgrafix.demon.co.uk!betanews.demon.net!demon!news.sprintlink.net!uunet!news.tuwien.ac.at!hp
|>From: h...@vmars.tuwien.ac.at (Peter Holzer)
|>Newsgroups: comp.os.linux.development
|>Subject: Re: Alpha Linux
|>Date: Tue, 6 Sep 94 16:40:03 BST
|>Organization: University of Technology, Vienna, Dept. for Realtime Systems, AUSTRIA
|>Lines: 25
|>Message-ID: <34i2gj$9...@news.tuwien.ac.at>
|>References: <33govp$n...@solaris.cc.vt.edu> <33jad7$6...@clarknet.clark.net> <AMBRISKO.94...@tasha.kpc.com> <34htt5$7...@news.tuwien.ac.at>
|>NNTPPostingHost: quasi.vmars.tuwien.ac.at
|>XNewsreader: NN version 6.5.0 #7 (NOV)
|>
|>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
|>
|>>In article <AMBRISKO.94...@tasha.kpc.com>, ambr...@kpc.com (Douglas Ambrisko) writes:
|>>|> The biggest task with the
|>>|> Alpha is making everything 64 bit clean and this will apply to the EISA
|>>|> drivers.
|>
|>I sure hope it will be. Who wants a 32 bit OS on an Alpha?
|>
|>>If it will be, I hope
|>
|>Then you have to drop either the 16 bit or the 32 bit int type. Both
|>options may make some people unhappy. The 32 bit int is a reasonable
|>compromise. It also breaks all those programs which assume that a
|>pointer and an int are just the same thing, which is a good thing IMHO.
|>
The other option of course is to to provide a compiler flag which forces the
code to be loaded into the low 32 bits of memory, and then your program will
not break (generally !!). I personally do not like this idea but the DEC
C compiler for OSF/1 has such a flag and I know of projects where this falg has
saved a tremendous amount of reworking of existing code.
___ ___
|\ | | Steve youngs
| \ |\ \ | N.C. Graphics,
| \| \__ \__| Waterbeach, Cambridge
N.C. Graphics (Cambridge) Ltd. Tel:(0223) 861539 UK, CB5 9NN
Anton Ertl
|>
|> >In article <AMBRISKO.94...@tasha.kpc.com>, ambr...@kpc.com (Douglas Ambrisko) writes:
|> >|> The biggest task with the
|> >|> Alpha is making everything 64 bit clean and this will apply to the EISA
|> >|> drivers.
|>
|> >Only if Linux on the Alpha will be a 64-bit-OS.
|>
|> I sure hope it will be. Who wants a 32 bit OS on an Alpha?
The VMS guys. And I prefer a true 32-bit OS to a half-hearted 64-bit
OS, where one of the main data types of the main language is 32 bits:
Mark my words: As soon as people will be using really more tha 4G in
one app, they will complain about 32-bit ints as they do about 8086
segments now.
|> >If it will be, I hope
|> >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|>
|> Then you have to drop either the 16 bit or the 32 bit int type.
No. Just add an int32_t.
|> Both
|> options may make some people unhappy. The 32 bit int is a reasonable
|> compromise. It also breaks all those programs which assume that a
|> pointer and an int are just the same thing, which is a good thing IMHO.
Why is this a good thing? And is it also a good thing that programs
break that assume that an index into an array or the difference
between to pointers fits into an int?
And if you say, that such things can be easily fixed by greping for
"int" and replacing it with "TrueInt", you are wrong. In C int is not
just another type, it affects many things in the language: Normal
integer constants have the int type, int plays a special role in
conversion rules, switch wants an int argument, etc.
I have debugged enough programs (one:-) that worked perfectly well on
decent OSs on an Atari ST to know why I dislike
sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
least 5 hours of debugging time of two people (one of them an
experienced Atari user).
Tor Arntsen
>>>16 bits = short int
>>>32 bits = int
>>>64 bits = long
>
>This is, what OSF/1 does. So `the OSF/1 idiocy' bemoaned by Anton must
And IRIX 6 as far as I know.
--
Tor
Richard Coleman
> : 16 bits = short int
> : 32 bits = int
> : 64 bits = long
>
> 128 bits = long long :)
I've always thought that C should have some way
of letting you decided how many bytes to use
for your computation. It could be as simple as
having the types
int8 ( = char )
int16 ( = short )
int24
int32 ( = int )
...
up to some reasonable value like
int128. Of course, other syntatic sugar
would probably be necessary, but the idea
*appears* simple enough.
As we move to 64bit chips and beyond, it seems
like this will become very desirable.
Richard Coleman
col...@math.gatech.edu
Bill Hay
> Why drop one?
> 16 bits = short int
> 32 bits = int
> 64 bits = long
Because an int should be the natural wordsize of the processor and should
therefore be 64 bits.
--
Bill Hay
David Holland
> Why drop one?
> 16 bits = short int
> 32 bits = int
> 64 bits = long
Over in the next thread people were talking about Unicode; why not
16 bits = char
32 bits = short
64 bits = int, long
Of course that would break a lot of things, but such is the price of
progress :-)
--
- David A. Holland | -- "Do you have a moment?" -- "Yes.
dhol...@husc.harvard.edu | Unfortunately, it's a moment of inertia."
Alan Cox
>Another observation: at least according to the K&R C specification, short
>int, int, and long int are not defined to be any specific bit length, and
>can all be equal to same bit length, as a matter of fact. The programmer
>who writes expecting short int = 16 bits should know that the code will not
>necessarily be portable.
>
>Therefore, there shouldn't be a problem defining
>
>short int = 32 bits
>int = 64 bits
>long int = 64 bits
Indeed not. Do we get 128 bit long longs in gcc however ?. The other thing
people for get is char != 8 bits always. The Honeywell L66 had
char=9bits(*) (or 7 depending upon compiler setting), short=36bit, int=36bit,
long=36bit). Made for some porting fun.
(*) 4 or 5 chars per machine word.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
Anton Ertl
|> Do we get 128 bit long longs in gcc however ?
gcc defines long long to be twice as long as long. So if long is 64
bits, we should have 128-bit long longs. On the MIPS there are options
(not working yet according to the gcc-2.4.x manual) `-mint64',
`-mlong64' and `-mlonglong128'.
Of course, the Alpha OSF/1 people did not use up all idiocy in
defining ints, so they defined both long and long long as having 64
bits.
Ralf Baechle
|> : 16 bits = short int
|> : 32 bits = int
|> : 64 bits = long
|>
|> 128 bits = long long :)
Try -mlonglong128 which should be working for MIPS with gcc >= 2.6.0 :-)
Ralf
Lloyd Miller
> a...@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
> > Why drop one?
> > 16 bits = short int
> > 32 bits = int
> > 64 bits = long
> Over in the next thread people were talking about Unicode; why not
> 16 bits = char
> 32 bits = short
> 64 bits = int, long
> Of course that would break a lot of things, but such is the price of
> progress :-)
So you would agree with perhaps:
8 bits = short char
16 bits = long char
32 bits = short int
64 bits = long int
the default char and int sizes could be comile time / command line
options. The short and long qualifiers are already part of the language
anyway.
I agree with those who dislike the current GNU C "long long int" for 64
bits.
--
Lloyd Miller, Calgary Disclaimer:
ll...@lfmcal.cuc.ab.ca I never wrote any of this.
Terminal Insomniac And besides, I got it all wrong.
Kjetil Torgrim Homme
| I've always thought that C should have some way of letting you
| decided how many bytes to use for your computation.
I once saw someone on Usenet suggest this convention:
int8, int16, int32, ...:
Variables that should be exactly this size.
int8u, int16u, int32u, ...:
Variables that can be larger to increase speed. Many machines
would have a 32-bit int16u.
In addition, you'd want unsigned versions like "uint8" etc.
Kjetil T.
Joe Zbiciak
>What is the natural word size of the 68000? Or the 8088? Or a
Even better: The 68008... 8 bit data path, 16 bit registers, 32 bit ALU.
By 32 bit ALU, I mean two registers would combine together and make a 32 bit
register for ADD & SUB and MUL & DIV (I think.)
--Joe
James Logajan
> I've always thought that C should have some way
> of letting you decided how many bytes to use
> for your computation. It could be as simple as
> having the types
>
> int8 ( = char )
> int16 ( = short )
> int24
> int32 ( = int )
> ...
I second that motion. It is time people stopped kidding themselves and
realize that 'C' and 'C++' are really just turbo-charged assembly
languages. It seems absurd that after 20+ years we still deal with
address pointer arithmetic so much in complex applications. The idea that
the "size" of our base types is somehow "configurable" really just adds
an uneeded complexity. And these synonyms could be added into the language
without too much difficulty.
William Henning
>Then you have to drop either the 16 bit or the 32 bit int type. Both
>options may make some people unhappy. The 32 bit int is a reasonable
>compromise. It also breaks all those programs which assume that a
>pointer and an int are just the same thing, which is a good thing IMHO.
How about
short = 16 bits
int = 32 bits
long = 64 bits ?
Bill
--
----
bhen...@bhami.wimsey.com - Linux & OS/2 user at home, OS/2 developer at work
Albert D. Cahalan
> Why drop one?
> 16 bits = short int
> 32 bits = int
> 64 bits = long
Over in the next thread people were talking about Unicode; why not
16 bits = char
32 bits = short
64 bits = int, long
Of course that would break a lot of things, but such is the price of
progress :-)
That would actually make sense, except there isn't a data type 'byte'.
Perhaps this would work:
8 bits = byte
16 bits = char
32 bits = short
64 bits = int
128 bits = long (done by the compiler with 64 bit instructions)
--
Albert Cahalan
a...@meceng.coe.neu.edu
Bill Spitzak
I suggested that this be done with field notation:
int:8 // use at least 8 bits
int:8:8 // use exactly 8 bits
int:8:32 // use somewhere between 8 and 32 bits
Bill
Herbert Xu
: a...@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
: > Why drop one?
: > 16 bits = short int
: > 32 bits = int
: > 64 bits = long
: Over in the next thread people were talking about Unicode; why not
: 16 bits = char
: 32 bits = short
: 64 bits = int, long
: Of course that would break a lot of things, but such is the price of
: progress :-)
Only non-ANSI conforming C codes.
--
A. B <=> True B. A <=> False
Email: Herbert Xu ~{PmV>HI~} <her...@greathan.apana.org.au>
PGP Key: pgp-pub...@pgp.mit.edu or any other key sites
N J Plant
On the 68000 the external address bus is 20 bits and the external data bus
is 8. Internally, the registers, buses and ALU are all 32 bit. It can ADD
and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
result. It has fewer pins than a 68040, but its still a 32 bit chip. The
sizeof the integral types should be the same as any other 68K chip.
The Intel 8088 has a 20 bit address bus, but is otherwise an 8 bit device.
So:
short = 8 bits
int = 16 bits
long = 16 bits
Neither of these processors has the address space or MMU necessary for
Linux to run on them, so the natural word size is irrelevant.
>How do you define the "natural wordsize" nowadays?
On the alpha the instruction word length is 32 bits. The registers are
64 bit and there is plenty of them. I'd go for:
short = 32 bits To save memory on kernal data structures which need
to be in our level 2 cache.
int = 64 bits Small enough to avoid any significant performance
penalty on file system hashing. Large enough for the
next generation of disk drives.
long = 128 bits Large enough for most other purposes.
Nick
--
N J Plant
Richard Henderson
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Why is this a good thing? And is it also a good thing that programs
>break that assume that an index into an array or the difference
>between to pointers fits into an int?
That is exactly what the ANSI types size_t and ptrdiff_t are
for -- use them.
>And if you say, that such things can be easily fixed by greping for
>"int" and replacing it with "TrueInt", you are wrong. In C int is not
>just another type, it affects many things in the language: Normal
>integer constants have the int type, int plays a special role in
>conversion rules, switch wants an int argument, etc.
No, switch wants a scalar. And what do you mean by "normal"
integer constants? With sizeof(int) == 2, sizeof(long) == 4,
32768 unadorned with "L" is a long constant.
>I have debugged enough programs (one:-) that worked perfectly well on
>decent OSs on an Atari ST to know why I dislike
>sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
>least 5 hours of debugging time of two people (one of them an
>experienced Atari user).
I'll hazzard a guess that the problem of 3 vs 3L likely came
from not prototyping properly?
In short, there aren't nearly as many problems with
sizeof(int) != sizeof(void*) as you'd like to believe.
r~
Chris Bitmead
>a...@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
>
> > Why drop one?
> > 16 bits = short int
> > 32 bits = int
> > 64 bits = long
>
>Over in the next thread people were talking about Unicode; why not
>
>16 bits = char
>32 bits = short
>64 bits = int, long
None of these is the best solution. The best solution is to say exactly
what you mean. E.g. If you want to store numbers between -500 and +1000
you should declare this and let the compiler work out how many bits to
use. e.g. int{-500,1000} foo; int{0,65535} bar;
Naturally you could use typedef's for common ranges. This has the added
benefit of not assuming that the computer is binary, assuming one day
someone invents a non-binary computer.
In any case stating what you *really* want to do and letting the compiler
decide on the optimum number of bits has to be the best.
David Willmore
Nope, sorry. The 68008 had an 8 bit data path, 32 bit registers, 32 bit
ALU. The only funny thing about this chip was the small bus.
Cheers,
David
--
___________________________________________________________________________
will...@iastate.edu | "Death before dishonor" | "Better dead than greek" |
David Willmore | "Ever noticed how much they look like orchids? Lovely!" |
---------------------------------------------------------------------------
Lawrence Kirby
kjet...@mnemosyne.uio.no "Kjetil Torgrim Homme" writes:
>+--- Richard Coleman:
>| I've always thought that C should have some way of letting you
>| decided how many bytes to use for your computation.
>
>I once saw someone on Usenet suggest this convention:
>
> int8, int16, int32, ...:
> Variables that should be exactly this size.
Bad idea since there is no guarantee that these sizes are available to
an implementation so they are inherently nonportable and not particularly
useful.
> int8u, int16u, int32u, ...:
> Variables that can be larger to increase speed. Many machines
> would have a 32-bit int16u.
You're just defining int16u to be precisely what plain int is. The only
useful one is int32u which I would just call int32. And I would define it
as 'the smallest type the implementation can reasonably support which can
represent the entire range -2147483647 to 2147483647'.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Maarten Boekhold (Who'd you expect??)
> In article <im14u2c.779230562@cegt201>
> im1...@cegt201.bradley.edu "Joe Zbiciak" writes:
> >
> >In <JEM.94Se...@delta.hut.fi> j...@snakemail.hut.fi (Johan Myreen)
> >writes:
> >
> >>What is the natural word size of the 68000? Or the 8088? Or a
> >
> >Even better: The 68008... 8 bit data path, 16 bit registers, 32 bit ALU.
> >By 32 bit ALU, I mean two registers would combine together and make a 32 bit
> >register for ADD & SUB and MUL & DIV (I think.)
> >
> On the 68000 the external address bus is 20 bits and the external data bus
> is 8. Internally, the registers, buses and ALU are all 32 bit. It can ADD
> and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
> result. It has fewer pins than a 68040, but its still a 32 bit chip. The
> sizeof the integral types should be the same as any other 68K chip.
Ho, hold it right there...... The 68000 has a 16 bit external databus.
You're right about the other things though... :-)
Maarten
boek...@morra.et.tudelft.nl
Maarten Boekhold (Who'd you expect??)
I really like this solution. It might take some time to get used to, but I
like the idea.
Maarten
boek...@morra.et.tudeft.nl
Kai Petzke
>> On the 68000 the external address bus is 20 bits and the external data bus
>> is 8. Internally, the registers, buses and ALU are all 32 bit. It can ADD
>> and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
>> result. It has fewer pins than a 68040, but its still a 32 bit chip. The
>> sizeof the integral types should be the same as any other 68K chip.
On 68000, the data bus is 16, and the address bus is 24 (?) bit wide.
On 68008, the data bus is 8, and the address bus is 20 bits.
On both chips, the registers are 32 bit, but the ALU is 16 bit. So
32 bit ADDition and SUBtractions take twice as long as the 16 bit
operations. Starting from 68020, these chips are true 32 bit.
Kai
--
Kai Petzke | How fast can computers get?
Technical University of Berlin |
Berlin, Germany | Sol 9, of course, on Star Trek.
w...@marie.physik.tu-berlin.de |
Shannon Hendrix
>On the 68000 the external address bus is 20 bits and the external data bus
The 68000 has a 24-bit address bus. 20 bits is only 1mb RAM. 24-bits is
16mb RAM which is the 68000's limit I think. I know the Atari ST's
could put more than 20 bits on the address lines.
Also, the external data bus was 16-bits.
What I do a lot in my C code to avoid bit size problems is define
variables as int8, int16, int32, and int64. These are typedef's in
a machine dependent header file.
Of course, I only do this when I absolutely have to. I try to write
code where the range doesn't matter or will fit within 32-bits (I
don't worry about supporting 16-bit OS's much).
It may be flawed but it has saved me a lot of headache in some projects.
>Nick
>--
>N J Plant
--
csh
---------------------------------------------------------------------------
shen...@escape.widomaker.com | Linux and BSD
Eelco H. Essenberg
Chris Bitmead <chr...@wombat.cssc-syd.tansu.com.au> wrote:
>In article <DHOLLAND.9...@husc7.harvard.edu> dhol...@husc7.harvard.edu (David Holland) writes:
>
>>a...@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
>>
>
>None of these is the best solution. The best solution is to say exactly
>what you mean. E.g. If you want to store numbers between -500 and +1000
>you should declare this and let the compiler work out how many bits to
>use. e.g. int{-500,1000} foo; int{0,65535} bar;
I don't want to start any language feuds here, but of course there is a
language that already allows you to do exactly this: it's called ADA.
The notation is a little different, but basically you can tell it what
range (and what precision!) you want for a certain type, and it will figure
out how to handle that according to your platform. Of course if you specify
something your platform is unable to handle the compiler will spit at you :-)
>Naturally you could use typedef's for common ranges. This has the added
>benefit of not assuming that the computer is binary, assuming one day
>someone invents a non-binary computer.
>In any case stating what you *really* want to do and letting the compiler
>decide on the optimum number of bits has to be the best.
>
Exactly what Ada's predefined types are. As a sideline: ternary computers
have been tried if my memory is correct, but it seems they weren't too hot
or very practical...
Regards,
Eelco.
--
-------------------------=< Eelco Essenberg >=------------------------------
E.Ess...@TWI.TUDelft.NL f...@ftp.twi.tudelft.nl
FTP Manager: ftp.twi.tudelft.nl
<a href=http://www.twi.tudelft.nl/People/E.Essenberg.html>Click me!</a>
Maarten Boekhold (Who'd you expect??)
> >> On the 68000 the external address bus is 20 bits and the external data bus
> >> is 8. Internally, the registers, buses and ALU are all 32 bit. It can ADD
> >> and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
> >> result. It has fewer pins than a 68040, but its still a 32 bit chip. The
> >> sizeof the integral types should be the same as any other 68K chip.
> On 68000, the data bus is 16, and the address bus is 24 (?) bit wide.
> On 68008, the data bus is 8, and the address bus is 20 bits.
Well, strictly spoken, the address-bus is 23 bits wide. However, these
address *words* (ie. 16 bits). To be able to address bytes, it has 2
lines (UB and LB ?) to distingish between the upper byte and the lower byte.
I guess this was done to make the internal design easier.
Maarten
boek...@morra.et.tudelft.nl
Dan Pop
>In article <CHRISB.94S...@wombat.cssc-syd.tansu.com.au>,
>Chris Bitmead <chr...@wombat.cssc-syd.tansu.com.au> wrote:
>>
>>None of these is the best solution. The best solution is to say exactly
>>what you mean. E.g. If you want to store numbers between -500 and +1000
>>you should declare this and let the compiler work out how many bits to
>>use. e.g. int{-500,1000} foo; int{0,65535} bar;
>
>I don't want to start any language feuds here, but of course there is a
>language that already allows you to do exactly this: it's called ADA.
>The notation is a little different, but basically you can tell it what
>range (and what precision!) you want for a certain type, and it will figure
>out how to handle that according to your platform. Of course if you specify
>something your platform is unable to handle the compiler will spit at you :-)
Another language that can do exactly the same thing is Fortran (in its
latest incarnation: F90).
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Larry Pyeatt
In article <Cw4DE...@news.cern.ch>, dan...@cernapo.cern.ch (Dan Pop) writes:
|> In <Cw33A...@dutiws.twi.tudelft.nl> esse...@dutiws.twi.tudelft.nl (Eelco H. Essenberg) writes:
|>
|> >In article <CHRISB.94S...@wombat.cssc-syd.tansu.com.au>,
|> >Chris Bitmead <chr...@wombat.cssc-syd.tansu.com.au> wrote:
|> >>
|> >>None of these is the best solution. The best solution is to say exactly
|> >>what you mean. E.g. If you want to store numbers between -500 and +1000
|> >>you should declare this and let the compiler work out how many bits to
|> >>use. e.g. int{-500,1000} foo; int{0,65535} bar;
|> >
|> >I don't want to start any language feuds here, but of course there is a
|> >language that already allows you to do exactly this: it's called ADA.
|> >The notation is a little different, but basically you can tell it what
|> >range (and what precision!) you want for a certain type, and it will figure
|> >out how to handle that according to your platform. Of course if you specify
|> >something your platform is unable to handle the compiler will spit at you :-)
|>
|> Another language that can do exactly the same thing is Fortran (in its
|> latest incarnation: F90).
Has everyone forgotten about PL/1? It also allowed specification
in that manner. One of the only really nice features of PL/1.
--
Larry D. Pyeatt All standard disclaimers apply.
pye...@cs.colostate.edu Void where prohibited.
Dietmar Heidrich
: im1...@cegt201.bradley.edu (Joe Zbiciak) writes:
: >j...@snakemail.hut.fi (Johan Myreen) writes:
: >>What is the natural word size of the 68000? Or the 8088? Or a
: >Even better: The 68008... 8 bit data path, 16 bit registers, 32 bit ALU.
: >By 32 bit ALU, I mean two registers would combine together and make a 32 bit
: >register for ADD & SUB and MUL & DIV (I think.)
: Nope, sorry. The 68008 had an 8 bit data path, 32 bit registers, 32 bit
: ALU. The only funny thing about this chip was the small bus.
The 32 bit ALU was introduced with the 68020. The former family members,
including the 68008, have 16 bit ALUs, causing them to take longer for
32 bit addition etc. Refer to the instruction timing.
The 68008 has a 16 bit ALU. Period.
Toshiyasu Morita
: N J Plant (ni...@lepton.demon.co.uk) wrote:
: > In article <im14u2c.779230562@cegt201>
: > im1...@cegt201.bradley.edu "Joe Zbiciak" writes:
: > >
: > >In <JEM.94Se...@delta.hut.fi> j...@snakemail.hut.fi (Johan Myreen)
: > >writes:
: > >
: > >>What is the natural word size of the 68000? Or the 8088? Or a
: > >
: > >Even better: The 68008... 8 bit data path, 16 bit registers, 32 bit ALU.
: > >By 32 bit ALU, I mean two registers would combine together and make a 32 bit
: > >register for ADD & SUB and MUL & DIV (I think.)
: > >
: > On the 68000 the external address bus is 20 bits and the external data bus
: > is 8. Internally, the registers, buses and ALU are all 32 bit. It can ADD
: > and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
: > result. It has fewer pins than a 68040, but its still a 32 bit chip. The
: > sizeof the integral types should be the same as any other 68K chip.
Nope, if I remember correcty the 68000 and 68008 technically have a 16-bit
ALU. If you don't believe me, look at the cycle counts for the 68000 when
doing 8/16 bit adds versus 32 bit adds...the 32-bit add takes an extra
4 clock cycles because it has to run the data the high word through the
ALU as well, even on register-to-register operatoions.
: Ho, hold it right there...... The 68000 has a 16 bit external databus.
: You're right about the other things though... :-)
: Maarten
: boek...@morra.et.tudelft.nl
ObLinuxComment: The 2742-pre-alpha-4 drivers don't work on a NICE VLB/EISA
motherboard with edge-triggered EISA interrupts - anyone know why?
Toshi
t...@netcom.com
Timothy J. Kordas
: I don't want to start any language feuds here, but of course there is a
: language that already allows you to do exactly this: it's called ADA.
: The notation is a little different, but basically you can tell it what
: range (and what precision!) you want for a certain type, and it will figure
: out how to handle that according to your platform. Of course if you specify
: something your platform is unable to handle the compiler will spit at you :-)
no feud here...but *YOU* get to be the one to rewrite the kernel in ADA...
-Tim
--
Timothy J. Kordas | t...@nostromo.eeap.cwru.edu
Electrical Engineering and Applied Physics |
Case Western Reserve University | PGP public key available
Cleveland, Ohio 44106 | via finger
Mike Haertel
>Nope, if I remember correcty the 68000 and 68008 technically have a 16-bit
>ALU. If you don't believe me, look at the cycle counts for the 68000 when
>doing 8/16 bit adds versus 32 bit adds...the 32-bit add takes an extra
>4 clock cycles because it has to run the data the high word through the
>ALU as well, even on register-to-register operatoions.
Sorry, this is bogus, you are wrong.
The 68000 and 68008 both have a 32 bit ALU.
The extra 4 cycles (on the 68000) come when loading 32-bit values
from memory, where the cost is 4 cycles per 16-bit word loaded.
I assume on a 68008 the cost would be an extra 8 cycles.
Thus: a 32-bit register->register add is just as fast as a 16-bit one.
But a 32-bit memory->register or immediate->register is 4 (or 8)
cycles slower.
Why the heck are we talking about this in comp.os.linux?
--
Mike Haertel <mi...@ichips.intel.com>
Not speaking for Intel.
Andrew Bulhak
: In article <ADC.94Se...@bach.coe.neu.edu>,
: Albert D. Cahalan <a...@bach.coe.neu.edu> wrote:
: > >|> Alpha is making everything 64 bit clean and this will apply to the EISA
: > >|> drivers.
: >
: > >Only if Linux on the Alpha will be a 64-bit-OS.
: >
: > I sure hope it will be. Who wants a 32 bit OS on an Alpha?
: >
: > >If it will be, I hope
: > >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
: >
: > Then you have to drop either the 16 bit or the 32 bit int type. Both
: > options may make some people unhappy. The 32 bit int is a reasonable
: > compromise. It also breaks all those programs which assume that a
: > pointer and an int are just the same thing, which is a good thing IMHO.
: >Why drop one?
: >32 bits = int
: >64 bits = long
: Another observation: at least according to the K&R C specification, short
: int, int, and long int are not defined to be any specific bit length, and
: can all be equal to same bit length, as a matter of fact. The programmer
: who writes expecting short int = 16 bits should know that the code will not
: necessarily be portable.
: Therefore, there shouldn't be a problem defining
: short int = 32 bits
: int = 64 bits
: long int = 64 bits
: or all of them = 64 bits. This makes more sense to me than int = 32 bits.
Obviously you do not need to read files in binary formats much, or at
least not binary formats designed for older platforms. 16-bit quantities
are invaluable when dealing with file formats designed for MS-DOS
applications.
--
Andrew Bulhak a...@yoyo.cc.monash.edu.au
Remember the good old days, when "spam" on the Net referred to processed meat?
Andrew Bulhak
: Albert D. Cahalan (a...@bach.coe.neu.edu) wrote:
: : Why drop one?
(8 bits = char)
: : 16 bits = short int
: : 32 bits = int
: : 64 bits = long
: 128 bits = long long :)
This may merit discussion on comp.lang.c. Sooner or later, we will need
more sizes, as soon as somebody makes a 128-bit CPU.
Andrew Bulhak
: a...@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
: > Why drop one?
: > 16 bits = short int
: > 32 bits = int
: > 64 bits = long
: Over in the next thread people were talking about Unicode; why not
: 16 bits = char
: 32 bits = short
: 64 bits = int, long
8 bits = char
16 bits = wchar_t, short
32 bits = int
64 bits = long
: Of course that would break a lot of things, but such is the price of
: progress :-)
Why break that which is not broken, especially for such a trivial
reason? Unicode and other 16-bit encodings already have wchar_t, and
they are not going to replace ASCII in the near future.
--
Andrew Bulhak a...@yoyo.cc.monash.edu.au
BRAKE WHATEVER IS NOT BROKEN AND CHANGE IT !
Andrew Bulhak
: > Why drop one?
: > 16 bits = short int
: > 32 bits = int
: > 64 bits = long
: Because an int should be the natural wordsize of the processor and should
: therefore be 64 bits.
What is "natural"? An Alpha can handle 32-bit quantities just as
"naturally" as 64-bit quantities, so it all comes down to convenience.
And dropping one size, thus making it unavailable to programmers, is
very inconvenient.
Let's not fool ourselves. Some people say that that is a Good Thing as
it breaks poorly written applications and teaches Good Programming. This
is tantamount to asserting that self-flagellation is character-building.
In other words, it has more to do with masochism than with making a
usable system. Programming environments should not be about obstacles
for the sake of obstacles.
Just my $0.02;
Andrew Bulhak
: I have debugged enough programs (one:-) that worked perfectly well on
: decent OSs on an Atari ST to know why I dislike
: sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
: least 5 hours of debugging time of two people (one of them an
: experienced Atari user).
Since the converse ( "sizeof(int)==sizeof(void *)" ) is not specified in
the C specification, it should not be assumed. It is a pretty safe
assumption, however, that a long can hold both a pointer and an int.
Andrew Bulhak
: In article <CvuwH...@info.swan.ac.uk>, iia...@iifeak.swan.ac.uk (Alan Cox) writes:
: |> Do we get 128 bit long longs in gcc however ?
: gcc defines long long to be twice as long as long. So if long is 64
: bits, we should have 128-bit long longs. On the MIPS there are options
: (not working yet according to the gcc-2.4.x manual) `-mint64',
: `-mlong64' and `-mlonglong128'.
: Of course, the Alpha OSF/1 people did not use up all idiocy in
: defining ints, so they defined both long and long long as having 64
: bits.
That, granted, is short-sighted. Taking away a usable type, however, for
the purpose of righteous self-flagellation and catching out
"badly-written" programs seems to be more stupid than making an int
smaller than the maximum size of a machine word.
Kevin Marcus
Andrew Bulhak <acb...@penfold.cc.monash.edu.au> wrote:
>Bill Hay (wi...@dumain.demon.co.uk) wrote:
>What is "natural"? An Alpha can handle 32-bit quantities just as
>"naturally" as 64-bit quantities, so it all comes down to convenience.
>And dropping one size, thus making it unavailable to programmers, is
>very inconvenient.
Actually, the Alpha suffers significant performance penalties when dealing
with 32 bit vs. 64 bit quantities. (Yet another reason NT is slow on
the lower end Alpha's).
--
--> Kevin Marcus, Computer Science Dept., University of California, Riverside
Email: dat...@cs.ucr.edu.
.. "Two types of programs do CALL <next instr>; POP <index reg>. They are
viruses and a good chunk of DOS programs. Down with MicroSloth."
Andrew Bulhak
: In article <AMBRISKO.94...@tasha.kpc.com>, ambr...@kpc.com (Douglas Ambrisko) writes:
: |> The biggest task with the
: |> Alpha is making everything 64 bit clean and this will apply to the EISA
: |> drivers.
: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
ints should be 32-bit, longs 64-bit and shorts 16-bit.
If both ints and longs were made 64-bit, one would have no access to
32-bit or 16-bit objects (depending on the size of a short). That would
break a lot of applications and cause headaches when dealing with file
formats.
I think that the OSF/1 solution (64-bit longs, 32-bit ints and 16-bit
shorts) is the best one; it seems to be intuitively logical (longs
should be long and may be longer than ints) and doesn't break much
(programs which depend on ints being 32-bit will still run).
--
Andrew Bulhak <a...@yoyo.cc.monash.edu.au> Celebrate PRODOS 1.1.1 DAY 18-Sep-94
Dan Pop
>Actually, the Alpha suffers significant performance penalties when dealing
>with 32 bit vs. 64 bit quantities. (Yet another reason NT is slow on
>the lower end Alpha's).
Which explains why all the machine code instructions on Alpha are 32
bits :-)
Before posting nonsense, please check your facts. Alpha supports both
32 and 64 bit memory access. It doesn't support byte access, however.
GARY K BARNES
Andrew Bulhak <acb...@penfold.cc.monash.edu.au> wrote:
>Steven A. Reisman (s...@bee.beehive.mn.org) wrote:
>: Albert D. Cahalan (a...@bach.coe.neu.edu) wrote:
>
>: : Why drop one?
>
>(8 bits = char)
>: : 16 bits = short int
>: : 32 bits = int
>: : 64 bits = long
>
>: 128 bits = long long :)
>
>This may merit discussion on comp.lang.c. Sooner or later, we will need
>more sizes, as soon as somebody makes a 128-bit CPU.
I just had great fun getting ufc-crypt and Crack to compile on
an Alpha. (Mind you, I did get a little help from Alec *8-])
I have to say it's worth it though, I now have a version of
crack that uses 64 bit integers and a ufc-crypt that can crypt
at about 4500 fcrypts/sec
Just to relate this to linux a little, cracking a passwd file on my
386dx25 Linux box took 5hrs 40mins to do the 1st (gecos) pass, whereas
it took 13mins 25secs to do the same pass on an Alpha running OSF/1 2.1.
Gaz
--
/\./\ g...@aber.ac.uk (Gary "Wolf" Barnes)
( - - ) Computer Officer, News Administrator
\ " / University of Wales, Aberystwyth
~~~ "It's just a ride..." - Bill Hicks
David Hinds
: Actually, the Alpha suffers significant performance penalties when dealing
: with 32 bit vs. 64 bit quantities. (Yet another reason NT is slow on
: the lower end Alpha's).
Are you sure about this? In my experience, on 64 bit architectures
(like MIPS R4x00, IBM POWER, Alpha, etc) using 32 bit quantities is
often significantly faster than going with the full 64 bits, probably
due to better cache utilization.
-- David Hinds
dhi...@allegro.stanford.edu
Jay Ashworth
>: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
>: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
A posting in cola about a week ago said that it would be a 32-bit os, with
access to long-longs.
Cheers,
-- jra
--
Jay R. Ashworth Ashworth
Designer High Technology Systems Consulting & Associates
ka1fjx/4
j...@baylink.com Linux: The Choice of a GNU Generation +1 813 790 7592
Andrew Bulhak
: acb...@penfold.cc.monash.edu.au (Andrew Bulhak) writes:
: >: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
: >: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
: A posting in cola about a week ago said that it would be a 32-bit os, with
: access to long-longs.
Is that Linus' Alpha Linux or the DEC port?
Kent A Vander Velden
>Just to relate this to linux a little, cracking a passwd file on my
>386dx25 Linux box took 5hrs 40mins to do the 1st (gecos) pass, whereas
>it took 13mins 25secs to do the same pass on an Alpha running OSF/1 2.1.
Great.
--
Kent Vander Velden
gra...@iastate.edu
Jay Ashworth
>Jay Ashworth (j...@zeus.IntNet.net) wrote:
>: acb...@penfold.cc.monash.edu.au (Andrew Bulhak) writes:
>: >: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
>: >: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
>: A posting in cola about a week ago said that it would be a 32-bit os, with
>: access to long-longs.
>Is that Linus' Alpha Linux or the DEC port?
Forgive me...
there are _two_ ports underway to the same chip??
(I believe it was in a post from Jim Paradis, which would mean DEC, but I
don't remember for sure.)
Cheers,
-- jra
--
Jay R. Ashworth High Technology Systems Comsulting Ashworth
Designer Linux: The Choice of a GNU Generation & Associates
ka1fjx/4
j...@baylink.com "Hey! Do any of you guys know how to Madison?" 813 790 7592
Larry McVoy
: > what you mean. E.g. If you want to store numbers between -500 and +1000
: > you should declare this and let the compiler work out how many bits to
: > use. e.g. int{-500,1000} foo; int{0,65535} bar;
#define int8 char
#define int16 short
#define int32 int
#define int64 long
These should have been in sys/types.h a long time ago along with the
unsigned versions. I've ported the TCP stack several times to weird
hardware where this sort of thing was desperately needed.
Before everyone says that "My weird ass machine doesn't have 16 bit
integers" note that you use these types when THESE ARE EXACTLY WHAT
YOU NEED. Like in protocol structures, where the size is determined
by the bits on the wire, not "My weird ass machine". Then if your
machine doesn't work, at least you get the errors right up front and
can go diddle your way around it.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
James Lewis Nance
In article <36agpt$h...@zeus.IntNet.net>, j...@zeus.IntNet.net (Jay Ashworth) writes:
>
> Forgive me...
>
> there are _two_ ports underway to the same chip??
>
> (I believe it was in a post from Jim Paradis, which would mean DEC, but I
> don't remember for sure.)
I believe that there are 2 people working on 1 port.
Jim Nance
jsm...@red-branch.mit.edu
: Jim Nance
The way I understand it, having talked with some of the people involved
second hand. The DEC fellow has done/is doing his own port, while Linus
is working on something seperate. However some of this information is
second hand to me so accuracy may be somewhat lacking.
Jonathan Smith
Chris Bitmead
>Jay Ashworth (j...@zeus.IntNet.net) wrote:
>: acb...@penfold.cc.monash.edu.au (Andrew Bulhak) writes:
>: >: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
>: >: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
>
>: A posting in cola about a week ago said that it would be a 32-bit os, with
>: access to long-longs.
>
>Is that Linus' Alpha Linux or the DEC port?
Linus' port is 64 bit. The DEC port is 32 bit.
David Holland
> Since the converse ( "sizeof(int)==sizeof(void *)" ) is not specified in
> the C specification, it should not be assumed. It is a pretty safe
> assumption, however, that a long can hold both a pointer and an int.
If you were running on a 386 in protected mode with full segmentation
turned on, this would not be the case (32 bit long vs. 56-bit pointer).
--
- David A. Holland | -- "Do you have a moment?" -- "Yes.
dhol...@husc.harvard.edu | Unfortunately, it's a moment of inertia."
Linus Torvalds
Just to clear things up a bit: there are indeed two different parties
working on this, but we really shouldn't talk about two different ports.
It's more a matter of different approaches, and the port done by Jim
Paradis is certainly 32-bit. This isn't as bad as it sounds: it just
means that the user-level VM is limited to about 2GB, as the Alpha
really is a native 64 bit chip and doesn't have separate 32/64 bit
modes.
[ small plug for the Alpha: I don't know about others, but I think the
Alpha chip is a helluva good chip. *Very* nice design ]
The port by Jim is going to be ready earlier, and I'm not quite stupid
enough to ignore what he has done: I expect the final Alpha port to be
quite heavily influenced on his work. I want to use the 64-bit version
of gcc to compile the eventual alpha-linux, not so much to break the 2GB
VM barrier as just to catch out some of the worst 32-bitisms in the
current kernel. Jim didn't want to worry about those right now.
In short, it's not "Linus vs DEC", but just stages of development and
different goals: Jim primarily wants a linux port to the Alpha, while my
main motivation is to play around with a very nice (and different and
FAST) machine. I hope the end result will be a well-balanced system ;-)
Linus
Jay Ashworth
>In article <CHRISB.94S...@wombat.cssc-syd.tansu.com.au>,
>Chris Bitmead <chr...@wombat.cssc-syd.tansu.com.au> wrote:
>>In article <365tbe$7...@harbinger.cc.monash.edu.au>,
>> acb...@penfold.cc.monash.edu.au (Andrew Bulhak) writes:
>>
>>>Jay Ashworth (j...@zeus.IntNet.net) wrote:
Gee...
I got followed up by Linus.
My Linus number is now 3.
Cool.
Ok, I'm over it now. BTW, what happened to the code freeze? :-)
Cheers,
-- jra
--
Jay R. Ashworth High Technology Systems Consulting Ashworth
Designer Linux: The Choice of a GNU Generation & Associates
ka1fjx/4 "When cryptography is outlawed, +1 813 790 7592
j...@baylink.com bayl bhgynjf jvyy unir cevinpl." -jpb NIC: jra3