HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/07/91)
This proposal relates to the last article: If struct messages contains only short and long (no 'int'), various parts of the system (user code, FS, MM, Kernel etc) can communicate irrespective of wether they are compiled in 16-bit or 32-bit mode. The FS must be modified since, e.g., a READ request must have a 'long' parameter for nbytes. I wonder if it is possible to build this into future MINIX versions. C.v.W.
klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (01/08/91)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >If struct messages contains only short and long (no 'int'), >various parts of the system (user code, FS, MM, Kernel etc) can >communicate irrespective of wether they are compiled in 16-bit or >32-bit mode. Why include the assumption that short == 16 bits and long == 32 bits? Please use something like int16 and int32 when you mean that. This will save you when using a machine where short=16, int=32 and long=64 bits. These names should be typedef'ed somewhere. Comments? Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!utrcu1!utep!utelmi01!klamer
burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) (01/09/91)
Klamer Schutte -- Universiteit Twente <klamer@MI.ELTN.UTWENTE.NL> writes: > >HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > >>If struct messages contains only short and long (no 'int'), >>various parts of the system (user code, FS, MM, Kernel etc) can >>communicate irrespective of wether they are compiled in 16-bit or >>32-bit mode. > >Why include the assumption that short == 16 bits and long == 32 bits? >Please use something like int16 and int32 when you mean that. >This will save you when using a machine where short=16, int=32 and long=64 bits > >These names should be typedef'ed somewhere. > >Comments? Wasn't the original definition of "short" and "long" from K&R explicit? I recall a page in the book describing the various lengths of the the types and "int" being the only machine-specific one. I think the definition was short: 8 bits and long: [16||32) i can't remember exactly)] bits. Besides, the compilers in question are virtually all written by and maintained by people on the net. If short is always eight bits and long is always 32 bits, then the idea (IMHO) is an excellent method to overcome the problems with variant "int" sizes. TSgt Dave Burgess Armstrong Labs Det 4 Brooks AFB, TX
klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (01/09/91)
burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) writes: >Klamer Schutte -- Universiteit Twente <klamer@MI.ELTN.UTWENTE.NL> writes: >> >> >>Why include the assumption that short == 16 bits and long == 32 bits? >>Please use something like int16 and int32 when you mean that. >>This will save you when using a machine where short=16, int=32 and long=64 bits >> >>These names should be typedef'ed somewhere. >> >>Comments? > Wasn't the original definition of "short" and "long" from K&R explicit? I No! >recall a page in the book describing the various lengths of the the types and >"int" being the only machine-specific one. I think the definition was >short: 8 bits and long: [16||32) i can't remember exactly)] bits. Besides, >the compilers in question are virtually all written by and maintained by >people on the net. If short is always eight bits and long is always 32 bits, short 8 bits ??? >then the idea (IMHO) is an excellent method to overcome the problems with >variant "int" sizes. #ifdef QUOTE_ON K&R, edition 1 (No ansi C!), ISBN 0-13-110163-3, 1978, page 34: DEC PDP-11 Honeywell 6000 (more machines) char 8 bits 9 bits 8 bits int 16 bits 36 bits 32 bits short 16 bits 36 bits 16 bits long 32 bits 36 bits 32 bits The intent is that short and long should provide different lengths of integers where practical; int will normally reflect the most "natural" size for a particular machine. As you can see, each compiler is free to interpret short and long as appropriate for its own hardware. About all you should count on is that short is no longer than long #endif /* QUOTE_ON*/ I thus interpret the choice of short=16, int=32 and long=64 bits as legal. (IMHO) Hey ansi guru's, what's new? Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!utrcu1!utep!utelmi01!klamer
nicolas@cli52or.edf.fr (01/09/91)
> > HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > > >If struct messages contains only short and long (no 'int'), > >various parts of the system (user code, FS, MM, Kernel etc) can > >communicate irrespective of wether they are compiled in 16-bit or > >32-bit mode. > > Why include the assumption that short == 16 bits and long == 32 bits? > Please use something like int16 and int32 when you mean that. > This will save you when using a machine where short=16, int=32 and long=64 bits. > > These names should be typedef'ed somewhere. > > Comments? > > Klamer > > -- > Klamer Schutte > Faculty of electrical engineering -- University of Twente, The Netherlands > klamer@mi.eltn.utwente.nl {backbone}!mcsun!utrcu1!utep!utelmi01!klamer > How 'long' can be 64 bits ? Are you speaking of a dialect of C ? Perhaps D .........
jerry@TALOS.UUCP (Jerry Gitomer) (01/09/91)
burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) writes: :Klamer Schutte -- Universiteit Twente <klamer@MI.ELTN.UTWENTE.NL: writes: :: :: [material not relevant to this reply deleted] :: ::Why include the assumption that short == 16 bits and long == 32 bits? ::Please use something like int16 and int32 when you mean that. ::This will save you when using a machine where short=16, int=32 and long=64 bits :: ::These names should be typedef'ed somewhere. :: ::Comments? : Wasn't the original definition of "short" and "long" from K&R explicit? I :recall a page in the book describing the various lengths of the the types and :"int" being the only machine-specific one. I think the definition was :short: 8 bits and long: [16||32) i can't remember exactly)] bits. Besides, :the compilers in question are virtually all written by and maintained by :people on the net. If short is always eight bits and long is always 32 bits, :then the idea (IMHO) is an excellent method to overcome the problems with :variant "int" sizes. Extracted from table on page 182 of K&R: DEC Honeywell IBM Interdata PDP-11 6000 370 8/32 int 16 bits 36 bits 32 bits 32 bits short 16 36 16 16 long 32 36 32 32 As can be seen the size of int, short, and long is machine dependent. As someone who does not use an 80x86 derivative I would prefer to see machine dependencies clearly delineated by using names such as short36 and long32 :-) -- Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA I am apolitical, have no resources, and speak only for myself. Ma Bell (703)683-9090 (UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jerry
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/10/91)
Well, int16 int32 etc are appropriate if the different parts which communicate are compiled not only in 16 or 32-bit mode, but also by incompatible compilers. In this case, different alignment/padding etc of structures may do any damage, but of course, it is more general to write int16, int32. The real point is that FS must be modified to accept 'long' nbyte parameters for read(fd, buf, nbyte) and write(fd, buf, nbyte) It should be no problem if fd is cast to short, but nbyte should ALWAYS be long to support user programs with int==long. C.v.W.
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (01/10/91)
In article <41145@nigel.ee.udel.edu> burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) writes: > Wasn't the original definition of "short" and "long" from K&R explicit? No. From K&R 2nd edition, page 36: The intent is that short and long should provide different lengths where practical; int will normally be the natural size for a particular machine. short is often 16 bits, long 32 bits, and int either 16 or 32 bits. Each compiler is free to choose appropriate sizes for its own hardware, subject to the restriction that shorts and ints are at least 16 bits, longs are at least 32 bits, and short is no longer than int, which is no longer than long. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
lunnon@qut.edu.au (01/10/91)
In article <41145@nigel.ee.udel.edu>, burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) writes: > Klamer Schutte -- Universiteit Twente <klamer@MI.ELTN.UTWENTE.NL> writes: >> >>HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >> >>>If struct messages contains only short and long (no 'int'), >>>various parts of the system (user code, FS, MM, Kernel etc) can >>>communicate irrespective of wether they are compiled in 16-bit or >>>32-bit mode. >> >>Why include the assumption that short == 16 bits and long == 32 bits? >>Please use something like int16 and int32 when you mean that. >>This will save you when using a machine where short=16, int=32 and long=64 bits >> >>These names should be typedef'ed somewhere. >> >>Comments? > Wasn't the original definition of "short" and "long" from K&R explicit? I > recall a page in the book describing the various lengths of the the types and > "int" being the only machine-specific one. I think the definition was > short: 8 bits and long: [16||32) i can't remember exactly)] bits. Besides, > the compilers in question are virtually all written by and maintained by > people on the net. If short is always eight bits and long is always 32 bits, > then the idea (IMHO) is an excellent method to overcome the problems with > variant "int" sizes. Yes, This would work UNTILL a 64 bit long compiler comes alomg :-( I vote for int16 and int32 BOB > > TSgt Dave Burgess > Armstrong Labs Det 4 > Brooks AFB, TX
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/10/91)
I think the point is: short is at least 16 bit long is at least 32 bit sizeof (short) <= sizeof(int) <= sizeof(long) C.v.W.
lunnon@qut.edu.au (01/10/91)
In article <41247@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > Well, int16 int32 etc are appropriate if the different parts which > communicate are compiled not only in 16 or 32-bit mode, but also by > incompatible compilers. > > In this case, different alignment/padding etc of structures may do > any damage, but of course, it is more general to write int16, int32. I agree, in my 32 bit port of the general Minix libraries so I could compile 32 bit binaries to run under the 16 bit kernels this is a problem however, this is easily overcome by coding the message packing routines explicitly in assembler OR by using #pragma pack(1) and doing your own padding I infact found a problem where the union order of the message union was significant. Re-ordering the union elements fixed this !!! I think you can count on consistent padding strategies in many cases there really is only one case that has problems (ie do you put a char in the low or high byte of the word) the solution is natural I think. > > The real point is that FS must be modified to accept 'long' nbyte parameters > for read(fd, buf, nbyte) and write(fd, buf, nbyte) > I thought it already did ???? I think under C library rule nbytes is a long or was that an ansi change ??? > It should be no problem if fd is cast to short, but nbyte should ALWAYS be > long to support user programs with int==long. > > C.v.W. PS to support 32 bit languages some sign extending around sys calls is needed, In order to accept 32bit parts in the kernel I have fixed this in mpx.s BOB R.Lunnon@qut.edu.au