Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29701 > unrolled thread
| Started by | cslarsen@gmail.com |
|---|---|
| First post | 2014-04-18 06:46 -0700 |
| Last post | 2014-05-25 16:30 -0700 |
| Articles | 20 on this page of 78 — 19 participants |
Back to article view | Back to comp.lang.forth
Recommendation of a Forth to embed in C cslarsen@gmail.com - 2014-04-18 06:46 -0700
Re: Recommendation of a Forth to embed in C Pablo Hugo Reda <pabloreda@gmail.com> - 2014-04-18 07:13 -0700
Re: Recommendation of a Forth to embed in C Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-18 16:41 +0200
Re: Recommendation of a Forth to embed in C jacko <jackokring@gmail.com> - 2014-04-18 11:31 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 03:08 -0400
Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 02:59 -0500
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 04:55 -0400
Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:15 -0500
Re: Recommendation of a Forth to embed in C Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-19 23:47 +0200
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 22:12 -0400
Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 02:41 -0500
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-21 21:16 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 18:37 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 02:48 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 16:15 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 20:58 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 23:36 -0700
Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-04-22 21:38 -1000
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-23 06:14 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 21:10 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-24 23:09 -0700
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-24 00:31 -0700
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-26 20:17 -0400
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-26 20:29 -0400
Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:07 -0500
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 07:54 -0400
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-22 05:27 -0700
Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:37 -0500
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 21:18 -0400
Re: Recommendation of a Forth to embed in C Melzzzzz <mel@zzzzz.com> - 2014-04-23 07:26 +0200
Re: Recommendation of a Forth to embed in C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-23 08:40 -0500
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-26 21:52 -0400
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 00:18 -0400
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-27 01:10 -0400
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 01:28 -0400
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-27 01:42 -0400
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 02:56 -0400
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-27 03:09 -0400
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 05:07 -0400
Re: Recommendation of a Forth to embed in C jkn_gg@nicorp.f9.co.uk - 2014-04-20 14:02 -0700
Re: Recommendation of a Forth to embed in C albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-21 01:27 +0000
Re: Recommendation of a Forth to embed in C rickman <gnuarm@gmail.com> - 2014-04-21 14:19 -0400
Re: Recommendation of a Forth to embed in C Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 20:35 +0200
Re: Recommendation of a Forth to embed in C andraszsoter@gmail.com - 2014-04-21 11:54 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-21 20:25 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 18:26 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 03:29 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 16:19 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 20:23 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-22 23:16 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 01:43 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:33 +0100
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:02 -0400
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-28 01:27 -0700
Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-04-27 22:56 -1000
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 05:42 -0400
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-28 04:24 -0700
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-28 13:43 +0100
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 08:06 -0400
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-29 19:22 +0100
Re: Recommendation of a Forth to embed in C David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 07:54 -0400
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-29 06:06 -0700
Re: Recommendation of a Forth to embed in C "Alex McDonald" <blog@rivadpm.com> - 2014-04-29 19:07 +0100
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-28 04:17 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 08:20 -0400
Re: Recommendation of a Forth to embed in C Mark Wills <markwills1970@gmail.com> - 2014-04-29 06:09 -0700
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothaver.cqm> - 2014-04-21 20:39 -0400
Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-04-18 22:24 -1000
Re: Recommendation of a Forth to embed in C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-19 05:02 -0400
Re: Recommendation of a Forth to embed in C Paul Rubin <no.email@nospam.invalid> - 2014-04-19 01:43 -0700
Re: Recommendation of a Forth to embed in C andraszsoter@gmail.com - 2014-04-21 09:30 -0700
Re: Recommendation of a Forth to embed in C "VisualForth.com" <babruehl@gmail.com> - 2014-05-25 15:31 -0700
Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-05-25 16:54 -1000
Re: Recommendation of a Forth to embed in C Paul Rubin <no.email@nospam.invalid> - 2014-05-25 22:29 -0700
Re: Recommendation of a Forth to embed in C "VisualForth.com" <babruehl@gmail.com> - 2014-05-26 10:45 -0700
Re: Recommendation of a Forth to embed in C "Elizabeth D. Rather" <erather@forth.com> - 2014-05-26 09:39 -1000
Re: Recommendation of a Forth to embed in C Paul Rubin <no.email@nospam.invalid> - 2014-05-25 16:30 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-21 01:27 +0000 |
| Message-ID | <53547407$0$25056$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29742 |
In article <88c99e6b-9fb4-45fb-a724-eb03a673ceec@googlegroups.com>, <jkn_gg@nicorp.f9.co.uk> wrote: >On Saturday, 19 April 2014 09:55:05 UTC+1, Rod Pemberton wrote: > >[...] > >> >> A byte by definition is exactly 8-bits. Bytecode uses only one byte to >> represent all instructions. With a 1:1 mapping of instructions to integer >> values, how can you have more than 256 words using only 8-bits per > >> instruction? > >No, a byte is not by definition 8 bits (though I agree people often talk >as if it were, which can be confusing) If I'm buying me next 4 Gbyte chip and there are only 7 bits in a byte, I sure as hell I'm going to complain. > >Now if we were talking about 'octet-code', that might be different... > >http://en.wikipedia.org/wiki/Byte > > J^n Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-04-21 14:19 -0400 |
| Message-ID | <lj3ndt$v3o$1@dont-email.me> |
| In reply to | #29745 |
On 4/20/2014 9:27 PM, Albert van der Horst wrote: > In article <88c99e6b-9fb4-45fb-a724-eb03a673ceec@googlegroups.com>, > <jkn_gg@nicorp.f9.co.uk> wrote: >> On Saturday, 19 April 2014 09:55:05 UTC+1, Rod Pemberton wrote: >> >> [...] >> >>> >>> A byte by definition is exactly 8-bits. Bytecode uses only one byte to >>> represent all instructions. With a 1:1 mapping of instructions to integer >>> values, how can you have more than 256 words using only 8-bits per > >>> instruction? >> >> No, a byte is not by definition 8 bits (though I agree people often talk >> as if it were, which can be confusing) > > If I'm buying me next 4 Gbyte chip and there are only 7 bits in > a byte, I sure as hell I'm going to complain. If you want 8 bits, then you should specify an octet. That is what the ITU does. I have seen bytes be anything from 6 bits to 12. :) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-21 20:35 +0200 |
| Message-ID | <lj3od2$f94$1@online.de> |
| In reply to | #29752 |
rickman wrote: > If you want 8 bits, then you should specify an octet. That is what the > ITU does. > > I have seen bytes be anything from 6 bits to 12. :) The original Byte of the Stretch machine from IBM was 8 bits. As usual, other people have stretched the terminology. The idea was that a character would fit into one byte, and therefore char=byte, but then of course, other machines had other character sizes. Today, the situation is much better, because the strange architectures have died out. Therefore, the current meaning of "byte" is "octet", and you only need to say "octet" when you are operating in a context, where "byte" is ambiguous, e.g. when you talk about computer history. Example: "The Stretch machine introduced the concept of the byte, which on Stretch was relly an octet, unlike the size on other machines of that time." -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | andraszsoter@gmail.com |
|---|---|
| Date | 2014-04-21 11:54 -0700 |
| Message-ID | <bf58a0e0-f9e3-402c-bd55-5a2835a9c9b5@googlegroups.com> |
| In reply to | #29752 |
If we allow any byte size at all, we get strange numbers on some architectures. The Wikipedia article says: > it is the smallest addressable unit of memory in many computer architectures. Now, Chuck's i21 could address memory as 20bit 'bytes' (which internally were loaded into registers that were 21 bit wide). OK, even that was some time ago so it probably qualifies as computer history... Andras On Monday, April 21, 2014 2:19:02 PM UTC-4, rickman wrote: > On 4/20/2014 9:27 PM, Albert van der Horst wrote: > > > >> On Saturday, 19 April 2014 09:55:05 UTC+1, Rod Pemberton wrote: > > >> > > >> [...] > > >> > > >>> > > >>> A byte by definition is exactly 8-bits. Bytecode uses only one byte to > > >>> represent all instructions. With a 1:1 mapping of instructions to integer > > >>> values, how can you have more than 256 words using only 8-bits per > > > >>> instruction? > > >> > > >> No, a byte is not by definition 8 bits (though I agree people often talk > > >> as if it were, which can be confusing) > > > > > > If I'm buying me next 4 Gbyte chip and there are only 7 bits in > > > a byte, I sure as hell I'm going to complain. > > > > If you want 8 bits, then you should specify an octet. That is what the > > ITU does. > > > > I have seen bytes be anything from 6 bits to 12. :) > > > > -- > > > > Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-21 20:25 -0400 |
| Message-ID | <op.xeozguvu6zenlw@localhost> |
| In reply to | #29752 |
On Mon, 21 Apr 2014 14:19:02 -0400, rickman <gnuarm@gmail.com> wrote: > On 4/20/2014 9:27 PM, Albert van der Horst wrote: >> In article <88c99e6b-9fb4-45fb-a724-eb03a673ceec@googlegroups.com>, >> <jkn_gg@nicorp.f9.co.uk> wrote: >>> On Saturday, 19 April 2014 09:55:05 UTC+1, Rod Pemberton wrote: >>>> A byte by definition is exactly 8-bits. Bytecode uses only one byte >>>> to represent all instructions. With a 1:1 mapping of instructions to >>>> integer values, how can you have more than 256 words using only 8-bits >>>> per instruction? >>> >>> No, a byte is not by definition 8 bits (though I agree people often >>> talk as if it were, which can be confusing) >> >> If I'm buying me next 4 Gbyte chip and there are only 7 bits in >> a byte, I sure as hell I'm going to complain. > > If you want 8 bits, then you should specify an octet. That is what the > ITU does. > > I have seen bytes be anything from 6 bits to 12. :) > Yes, C etc redefines bytes to not be 8-bits. However, those are *NOT* bytes by definition. Bytes are *EXACTLY* 8-bits. Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They defined a character of exactly 8-bits. They were the first to create standardized character sets. Teletypes prior to that had numerous proprietary, incompatbile character of different bit sizes. The actual term "byte" for 8-bits was created by Dr. Werner Buchholz, at least according to Bob Bemer. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-21 18:26 -0700 |
| Message-ID | <lj4ggt$2kl$1@dont-email.me> |
| In reply to | #29756 |
on 21/04/2014 17:25:35, "Rod Pemberton" wrote: > > Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They > defined a character of exactly 8-bits. ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit character in 1959, but it was not adopted for ASCII. > They were the first to create > standardized character sets. Teletypes prior to that had numerous > proprietary, incompatbile character of different bit sizes. The driver was telecommunication, not teletypes. Bob Bemer was interested in a code that allowed unambiguous transmission of data. R.W.Bemer, H.J.Smith, Jr., F.A.Williams, "Design of an improved transmission/data processing code", Commun. ACM 4, No. 5, 212-217, 225, 1961 May from http://www.bobbemer.com/PUBS-1.HTM (I can't find a reference and my memory may be faulty here) After ASCII was formalized in 1963, iirc the only ASCII machine prior to the early 1980s was one range of UNIVAC machines.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-22 03:29 -0400 |
| Message-ID | <op.xepi33sv6zenlw@localhost> |
| In reply to | #29759 |
On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 21/04/2014 17:25:35, "Rod Pemberton" wrote: >> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They >> defined a character of exactly 8-bits. > > ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit > character in 1959, but it was not adopted for ASCII. > I accept that the non-extended ASCII characters only need 7-bits for their representation. But, I don't accept that ASCII is only 7-bits and not 8-bits. My recollection is that ANSI X3.4-1986 defined *both* ASCII and extended ASCII. Of course, the last time I read that standard was over two decades ago ... So, AIR, extended ASCII are 8-bit characters with the high bit set. AIR, the extended ASCII character set was intended for platform specific, graphics, and math symbols. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-22 16:19 -0700 |
| Message-ID | <lj6tdt$gji$1@dont-email.me> |
| In reply to | #29763 |
on 22/04/2014 00:29:57, "Rod Pemberton" wrote: > On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 21/04/2014 17:25:35, "Rod Pemberton" wrote: > wrote: > >>> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They >>> defined a character of exactly 8-bits. >> >> ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit >> character in 1959, but it was not adopted for ASCII. >> > > I accept that the non-extended ASCII characters only need 7-bits > for their representation. But, I don't accept that ASCII is only > 7-bits and not 8-bits. > > My recollection is that ANSI X3.4-1986 defined *both* ASCII and > extended ASCII. Of course, the last time I read that standard > was over two decades ago ... So, AIR, extended ASCII are 8-bit > characters with the high bit set. AIR, the extended ASCII > character set was intended for platform specific, graphics, > and math symbols. > ISO/IEC 8859, an 8 bit extended ASCII was ratified in 1998. US-ASCII or ANSI X3.4-1986 was specifically 7 bits, and there is no mention of 8 bit encodings. > > Rod Pemberton >
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-22 20:23 -0400 |
| Message-ID | <op.xeqt1bj06zenlw@localhost> |
| In reply to | #29783 |
On Tue, 22 Apr 2014 19:19:19 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 22/04/2014 00:29:57, "Rod Pemberton" wrote: >> On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com> >> > wrote: >>> on 21/04/2014 17:25:35, "Rod Pemberton" wrote: >> wrote: >>>> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They >>>> defined a character of exactly 8-bits. >>> >>> ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit >>> character in 1959, but it was not adopted for ASCII. >>> >> I accept that the non-extended ASCII characters only need 7-bits >> for their representation. But, I don't accept that ASCII is only >> 7-bits and not 8-bits. >> >> My recollection is that ANSI X3.4-1986 defined *both* ASCII and >> extended ASCII. Of course, the last time I read that standard >> was over two decades ago ... So, AIR, extended ASCII are 8-bit >> characters with the high bit set. AIR, the extended ASCII >> character set was intended for platform specific, graphics, >> and math symbols. >> > > ISO/IEC 8859, an 8 bit extended ASCII was ratified in 1998. US-ASCII or > ANSI X3.4-1986 was specifically 7 bits, and there is no mention of 8 bit > encodings. > Please cite. I found mention in two academic sources which say that the ASCII standard defines extended ASCII. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-22 23:16 -0700 |
| Message-ID | <lj7lsr$7ng$1@dont-email.me> |
| In reply to | #29784 |
on 22/04/2014 17:23:25, "Rod Pemberton" wrote: > On Tue, 22 Apr 2014 19:19:19 -0400, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 22/04/2014 00:29:57, "Rod Pemberton" wrote: > > wrote: >>> On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com> > > wrote: >>> > wrote: > > wrote: >>>> on 21/04/2014 17:25:35, "Rod Pemberton" wrote: > > wrote: >>> wrote: > wrote: > >>>>> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They >>>>> defined a character of exactly 8-bits. >>>> >>>> ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit >>>> character in 1959, but it was not adopted for ASCII. >>>> >>> I accept that the non-extended ASCII characters only need 7-bits >>> for their representation. But, I don't accept that ASCII is only >>> 7-bits and not 8-bits. >>> >>> My recollection is that ANSI X3.4-1986 defined *both* ASCII and >>> extended ASCII. Of course, the last time I read that standard >>> was over two decades ago ... So, AIR, extended ASCII are 8-bit >>> characters with the high bit set. AIR, the extended ASCII >>> character set was intended for platform specific, graphics, >>> and math symbols. >>> >> >> ISO/IEC 8859, an 8 bit extended ASCII was ratified in 1998. US-ASCII or >> ANSI X3.4-1986 was specifically 7 bits, and there is no mention of 8 bit >> encodings. >> > > Please cite. I found mention in two academic sources which say that > the ASCII standard defines extended ASCII. > http://www.unicode.org/L2/L2006/06388-review-incits4.pdf
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-27 01:43 -0400 |
| Message-ID | <op.xeynis146zenlw@localhost> |
| In reply to | #29789 |
On Wed, 23 Apr 2014 02:16:58 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 22/04/2014 17:23:25, "Rod Pemberton" wrote: >> On Tue, 22 Apr 2014 19:19:19 -0400, Alex McDonald <blog@rivadpm.com> >> wrote: >>> on 22/04/2014 00:29:57, "Rod Pemberton" wrote: >>>> On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com> >>>> wrote: >>>>> on 21/04/2014 17:25:35, "Rod Pemberton" wrote: >>>>>> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They >>>>>> defined a character of exactly 8-bits. >>>>> >>>>> ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit >>>>> character in 1959, but it was not adopted for ASCII. >>>>> >>>> I accept that the non-extended ASCII characters only need 7-bits >>>> for their representation. But, I don't accept that ASCII is only >>>> 7-bits and not 8-bits. >>>> >>>> My recollection is that ANSI X3.4-1986 defined *both* ASCII and >>>> extended ASCII. Of course, the last time I read that standard >>>> was over two decades ago ... So, AIR, extended ASCII are 8-bit >>>> characters with the high bit set. AIR, the extended ASCII >>>> character set was intended for platform specific, graphics, >>>> and math symbols. >>> >>> ISO/IEC 8859, an 8 bit extended ASCII was ratified in 1998. US-ASCII or >>> ANSI X3.4-1986 was specifically 7 bits, and there is no mention of 8 >>> bit encodings. >> >> Please cite. I found mention in two academic sources which say that >> the ASCII standard defines extended ASCII. >> > > http://www.unicode.org/L2/L2006/06388-review-incits4.pdf Thank you for confirming what I stated. If you had read that, or even remotely skimmed it, I *seriously* doubt you would've posted that link in support of your argument. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-27 11:33 +0100 |
| Message-ID | <ljimdf$8po$1@dont-email.me> |
| In reply to | #29901 |
on 27/04/2014 06:43:29, "Rod Pemberton" wrote:
> On Wed, 23 Apr 2014 02:16:58 -0400, Alex McDonald <blog@rivadpm.com>
> > wrote:
>> on 22/04/2014 17:23:25, "Rod Pemberton" wrote:
> > wrote:
>>> On Tue, 22 Apr 2014 19:19:19 -0400, Alex McDonald <blog@rivadpm.com>
> > wrote:
>>> wrote:
> > wrote:
>>>> on 22/04/2014 00:29:57, "Rod Pemberton" wrote:
> > wrote:
>>>>> On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com>
> > wrote:
>>>>> wrote:
> > wrote:
>>>>>> on 21/04/2014 17:25:35, "Rod Pemberton" wrote:
> wrote:
>
>>>>>>> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They
>>>>>>> defined a character of exactly 8-bits.
>>>>>>
>>>>>> ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit
>>>>>> character in 1959, but it was not adopted for ASCII.
>>>>>>
>>>>> I accept that the non-extended ASCII characters only need 7-bits
>>>>> for their representation. But, I don't accept that ASCII is only
>>>>> 7-bits and not 8-bits.
>>>>>
>>>>> My recollection is that ANSI X3.4-1986 defined *both* ASCII and
>>>>> extended ASCII. Of course, the last time I read that standard
>>>>> was over two decades ago ... So, AIR, extended ASCII are 8-bit
>>>>> characters with the high bit set. AIR, the extended ASCII
>>>>> character set was intended for platform specific, graphics,
>>>>> and math symbols.
>>>>
>>>> ISO/IEC 8859, an 8 bit extended ASCII was ratified in 1998. US-ASCII or
>>>> ANSI X3.4-1986 was specifically 7 bits, and there is no mention of 8
>>>> bit encodings.
>>>
>>> Please cite. I found mention in two academic sources which say that
>>> the ASCII standard defines extended ASCII.
>>>
>>
>> http://www.unicode.org/L2/L2006/06388-review-incits4.pdf
>
> Thank you for confirming what I stated.
>
> If you had read that, or even remotely skimmed it,
> I *seriously* doubt you would've posted that link
> in support of your argument.
>
>
> Rod Pemberton
>
Seriously? As Rickman says elesewhere, I really hate to even discuss
things with you because you seem to pull stuff out of your butt.
ANSI X3.4-1986 was specifically 7 bits. The document referred to shows
that quite clearly. There is one reference to 8 bit codes but it is about
*different set of related standards* ("Appendix E Related Standards").
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-28 01:02 -0400 |
| Message-ID | <op.xe0f98d76zenlw@localhost> |
| In reply to | #29910 |
On Sun, 27 Apr 2014 06:33:19 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 27/04/2014 06:43:29, "Rod Pemberton" wrote:
>> On Wed, 23 Apr 2014 02:16:58 -0400, Alex McDonald <blog@rivadpm.com>
>> wrote:
>>> on 22/04/2014 17:23:25, "Rod Pemberton" wrote:
>>>> On Tue, 22 Apr 2014 19:19:19 -0400, Alex McDonald <blog@rivadpm.com>
>>>> wrote:
>>>>> on 22/04/2014 00:29:57, "Rod Pemberton" wrote:
>>>>>> On Mon, 21 Apr 2014 21:26:48 -0400, Alex McDonald <blog@rivadpm.com>
>>>>>>> on 21/04/2014 17:25:35, "Rod Pemberton" wrote:
>>>>>>>> Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They
>>>>>>>> defined a character of exactly 8-bits.
>>>>>>>
>>>>>>> ASCII is, by definition, a 7 bit code. Bemer suggested an 8 bit
>>>>>>> character in 1959, but it was not adopted for ASCII.
>>>>>>>
>>>>>> I accept that the non-extended ASCII characters only need 7-bits
>>>>>> for their representation. But, I don't accept that ASCII is only
>>>>>> 7-bits and not 8-bits.
>>>>>>
>>>>>> My recollection is that ANSI X3.4-1986 defined *both* ASCII and
>>>>>> extended ASCII. Of course, the last time I read that standard
>>>>>> was over two decades ago ... So, AIR, extended ASCII are 8-bit
>>>>>> characters with the high bit set. AIR, the extended ASCII
>>>>>> character set was intended for platform specific, graphics,
>>>>>> and math symbols.
>>>>>
>>>>> ISO/IEC 8859, an 8 bit extended ASCII was ratified in 1998. US-ASCII
>>>>> or
>>>>> ANSI X3.4-1986 was specifically 7 bits, and there is no mention of 8
>>>>> bit encodings.
>>>>
>>>> Please cite. I found mention in two academic sources which say that
>>>> the ASCII standard defines extended ASCII.
>>>
>>> http://www.unicode.org/L2/L2006/06388-review-incits4.pdf
>>
>> Thank you for confirming what I stated.
>>
>> If you had read that, or even remotely skimmed it,
>> I *seriously* doubt you would've posted that link
>> in support of your argument.
>
> Seriously?
Yes, SERIOUSLY.
I found it in there seven times just from skimming it. Start by reading
page six. There is an entire paragraph on it there. Re-read page
six numerous times until it begins to sink in as to what it means. If
you're still not clear, then the extended appendices has a more thorough
paragraph in the additional appendix, in the 'E' section.
> As Rickman says elesewhere, I really hate to even discuss
> things with you because you seem to pull stuff out of your butt.
Apparently, this is a failure to comprehend on your part.
> ANSI X3.4-1986 was specifically 7 bits. The document referred to shows
> that quite clearly. There is one reference to 8 bit codes but it is about
> *different set of related standards* ("Appendix E Related Standards").
Yes, but the PDF you posted defines that. It defines where and how the
7-bit ASCII sequence are extended. It defines both control sequences in
the specification, and the option of extended 8-bit ASCII. It also
provides the name of the standard where the 8-bit extended ASCII is
fully defined: ANSI X3.41-1974.
So, yes, totally and completely seriously, ASCII supports extended
ASCII which are 8-bits, i.e., ASCII is not *only* 7-bits. It also
confirms my recollection that ASCII standard defines extended ASCII.
(I knew that. That's where I learned about it.)
Unfortunately, my recollection was that this was all one specification,
not two, but that doesn't matter. "It's in there."
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-28 01:27 -0700 |
| Message-ID | <e3bc2570-d2ec-4157-b421-5683558798aa@googlegroups.com> |
| In reply to | #29924 |
>So, yes, totally and completely seriously, ASCII supports extended >ASCII which are 8-bits, i.e., ASCII is not *only* 7-bits. Sure. But your original statement was: Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They defined a character of exactly 8-bits. To be fair, you later said: I accept that the non-extended ASCII characters only need 7-bits for their representation. But, I don't accept that ASCII is only 7-bits and not 8-bits. The Wikipedia page for ASCII (not authoratative, I accept) states: The American Standard Code for Information Interchange (ASCII /ˈæski/ ASS-kee)[1] is a character-encoding scheme originally based on the English alphabet that encodes 128 specified characters - the numbers 0-9, the letters a-z and A-Z, some basic punctuation symbols, some control codes that originated with Teletype machines, and a blank space - into the 7-bit binary integers.[2] ASCII developed from telegraphic codes. Its first commercial use was as a seven-bit teleprinter code promoted by Bell data services. Work on the ASCII standard began on October 6, 1960, with the first meeting of the American Standards Association's (ASA) X3.2 subcommittee. The first edition of the standard was published during 1963,[3][4] a major revision during 1967,[5] and the most recent update during 1986.[6] When one checks reference [6] one finds it is entitled: American National Standard for Information Systems — Coded Character Sets — 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII), ANSI X3.4-1986. American National Standards Institute. March 26, 1986 From what I can gather reading online, the ASCII character set is a 7 bit code. IBM later extended it to 8 bits, known as EBCDIC, but the 8-bit version has been (incorrectly) referred to as ASCII. Unfortunately I don't subscribe to ANSI.org so I wasn't able to download the actual PDF of the standard tect, and didn't manage to find a copy during my brief search. But it looks like ASCII is a 7-bit system and the 8-bit system we all know so well isn't actually ASCII, but EBCDIC, which is an IBM extension of ASCII. I didn't know that, so I've learned something, and it's only 9.25am!
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-27 22:56 -1000 |
| Message-ID | <0cidnddgqeVBisPOnZ2dnUVZ_hednZ2d@supernews.com> |
| In reply to | #29929 |
On 4/27/14 10:27 PM, Mark Wills wrote: >> So, yes, totally and completely seriously, ASCII supports extended >> ASCII which are 8-bits, i.e., ASCII is not *only* 7-bits. > > Sure. But your original statement was: > > Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They defined a character of exactly 8-bits. > > To be fair, you later said: > > I accept that the non-extended ASCII characters only need 7-bits for their representation. But, I don't accept that ASCII is only 7-bits and not 8-bits. > > > The Wikipedia page for ASCII (not authoratative, I accept) states: > > The American Standard Code for Information Interchange (ASCII /ˈæski/ ASS-kee)[1] is a character-encoding scheme originally based on the English alphabet that encodes 128 specified characters - the numbers 0-9, the letters a-z and A-Z, some basic punctuation symbols, some control codes that originated with Teletype machines, and a blank space - into the 7-bit binary integers.[2] > > ASCII developed from telegraphic codes. Its first commercial use was as a seven-bit teleprinter code promoted by Bell data services. Work on the ASCII standard began on October 6, 1960, with the first meeting of the American Standards Association's (ASA) X3.2 subcommittee. The first edition of the standard was published during 1963,[3][4] a major revision during 1967,[5] and the most recent update during 1986.[6] > > When one checks reference [6] one finds it is entitled: American National Standard for Information Systems — Coded Character Sets — 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII), ANSI X3.4-1986. American National Standards Institute. March 26, 1986 > > From what I can gather reading online, the ASCII character set is a 7 bit code. IBM later extended it to 8 bits, known as EBCDIC, but the 8-bit version has been (incorrectly) referred to as ASCII. > > Unfortunately I don't subscribe to ANSI.org so I wasn't able to download the actual PDF of the standard tect, and didn't manage to find a copy during my brief search. But it looks like ASCII is a 7-bit system and the 8-bit system we all know so well isn't actually ASCII, but EBCDIC, which is an IBM extension of ASCII. I didn't know that, so I've learned something, and it's only 9.25am! > EBCDIC is not just an 8-bit extension of 7-bit ASCII, it has very different representations for the symbols through the whole range. There's a comparison chart here: http://www.csgnetwork.com/ascebcdic.html. ANS Forth and the current Forth 200x documents resolve the issue by explicitly defining the values from 0-7F, referencing ANS X3.4-1974 (ASCII) and ISO 646-1983, International Reference Version (IRV). The segregation of the concepts "character" and "address unit" (and the avoidance of "byte") are ways of avoiding these wrangles. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-28 05:42 -0400 |
| Message-ID | <op.xe0s8gf96zenlw@localhost> |
| In reply to | #29929 |
On Mon, 28 Apr 2014 04:27:56 -0400, Mark Wills <markwills1970@gmail.com> wrote: >> So, yes, totally and completely seriously, ASCII supports extended >> ASCII which are 8-bits, i.e., ASCII is not *only* 7-bits. > > Sure. But your original statement was: > > Bob Bemer and Hugh McGregor Ross created ASCII and EBCDIC. They defined > a character of exactly 8-bits. > That's true. > To be fair, you later said: > > I accept that the non-extended ASCII characters only need 7-bits for > their representation. But, I don't accept that ASCII is only 7-bits > and not 8-bits. > That's true too. > The Wikipedia page for ASCII (not authoratative, I accept) states: > > The American Standard Code for Information Interchange (ASCII /ˈæski/ > ASS-kee)[1] is a character-encoding scheme originally based on the > English alphabet that encodes 128 specified characters - the numbers > 0-9, the letters a-z and A-Z, some basic punctuation symbols, some > control codes that originated with Teletype machines, and a blank space > - into the 7-bit binary integers.[2] > > ASCII developed from telegraphic codes. Its first commercial use was as > a seven-bit teleprinter code promoted by Bell data services. Work on the > ASCII standard began on October 6, 1960, with the first meeting of the > American Standards Association's (ASA) X3.2 subcommittee. The first > edition of the standard was published during 1963,[3][4] a major > revision during 1967,[5] and the most recent update during 1986.[6] > > When one checks reference [6] one finds it is entitled: American > National Standard for Information Systems — Coded Character Sets — 7-Bit > American National Standard Code for Information Interchange (7-Bit > ASCII), ANSI X3.4-1986. American National Standards Institute. March 26, > 1986 > I don't see anything here that changes anything. > From what I can gather reading online, the ASCII character set is a 7 > bit code. No. The ASCII specification provides for 8-bit ASCII encodings. These are called extended ASCII characters. ASCII is not exclusively 7-bits. That's the entire point. This was proven in the pdf, an extended version of the ASCII standard, that Alex provide a link too. What you (and apparently Alex too) are saying is that because the ASCII standard allows a 7-bit subset of the character set to be used, then a byte and therefore a character as it was defined by Bob Bemer, Hugh McGregor Ross, and Dr. Werner Buchholz is not exactly eight bits, but seven. That's backwards. > IBM later extended it to 8 bits, known as EBCDIC, but the 8-bit version > has been (incorrectly) referred to as ASCII. I don't know where you get this. > Unfortunately I don't subscribe to ANSI.org so I wasn't able to download > the actual PDF of the standard tect, and didn't manage to find a copy > during my brief search. But it looks like ASCII is a 7-bit system and > the 8-bit system we all know so well isn't actually ASCII, but EBCDIC, > which is an IBM extension of ASCII. I didn't know that, so I've learned > something, and it's only 9.25am! > EBCDIC is not an extension of ASCII. It has a different character ordering and encodings. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-28 04:24 -0700 |
| Message-ID | <e191e402-4272-49f2-ad7e-28581357fb8d@googlegroups.com> |
| In reply to | #29931 |
On Monday, 28 April 2014 10:42:06 UTC+1, Rod Pemberton wrote: > What you (and apparently Alex too) are saying is that because the ASCII > standard allows a 7-bit subset of the character set to be used, then a > byte and therefore a character as it was defined by Bob Bemer, Hugh > McGregor Ross, and Dr. Werner Buchholz is not exactly eight bits, but > seven. Multiple issues with the above. You claim above that the ASCII standard allows a 7-bit "subset" (your term) of the character set to be used. It doesn't. The American Standard Code for Information Interchange is a 7-bit *set* (my term). A separate standard (see my earlier post) specifies a standardised method to extend the system into an 8-bit set. A byte may be 8 bits, 7 bits, or 11 bits, or anything else. That we commonly think of a byte as 8 bits is more down to a byte being "de-facto" defined as 8 bits. But I, and as far as I can tell tell, Alex, have placed no definition of the defintion of a byte in the context of transmitting ascii characters; nor does the ASCII standard define one. I only have access to the ISO standards via our subscription system; ANSI is un-available to me.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-28 13:43 +0100 |
| Message-ID | <ljlicq$a35$1@dont-email.me> |
| In reply to | #29934 |
on 28/04/2014 12:24:37, Mark Wills wrote: > On Monday, 28 April 2014 10:42:06 UTC+1, Rod Pemberton wrote: >> What you (and apparently Alex too) are saying is that because the ASCII >> standard allows a 7-bit subset of the character set to be used, then a >> byte and therefore a character as it was defined by Bob Bemer, Hugh >> McGregor Ross, and Dr. Werner Buchholz is not exactly eight bits, but >> seven. RP; I don't make that assertion at all. > > Multiple issues with the above. You claim above that the ASCII > standard all ows a 7-bit "subset" (your term) of the character set to > be used. It doesn' t. The American Standard Code for Information > Interchange is a 7-bit *set* (my term). A separate standard (see my > earlier post) specifies a standardis ed method to extend the system > into an 8-bit set. > > A byte may be 8 bits, 7 bits, or 11 bits, or anything else. That we > commonl y think of a byte as 8 bits is more down to a byte being > "de-facto" defined as 8 bits. But I, and as far as I can tell tell, > Alex, have placed no defi nition of the defintion of a byte in the > context of transmitting ascii char acters; nor does the ASCII standard > define one. ANS X3.4 was mainly concerned with ensuring the unambiguous interpretation of bits transmitted, and didn't need, nor did it care, to specify bytes. Even the 8 bit extension doesn't mention bytes. The name kind of gives this away; it's an information interchange specification, and doesn't have regard to a unit of transmission or storage or addressing. The IETF http://tools.ietf.org/search/rfc4949 defines ASCII as "A scheme that encodes 128 specified characters -- the numbers 0-9, the letters a-z and A-Z, some basic punctuation symbols, some control codes that originated with Teletype machines, and a blank space -- into the 7-bit binary integers. Forms the basis of the character set representations used in most computers and many Internet standards." > > I only have access to the ISO standards via our subscription system; > ANSI i s un-available to me. > National standards bodies are reluctant to re-engineer global standards, and ANSI quite clearly states that it does not develop standards; it accredits other bodies and adopts their standards. An ISO standard is generally adopted as an ANSI standard. ANSI is on ISO; http://www.ansi.org/standards_activities/iso_programs/overview.aspx?menuid=3 ANSI standards are expensive, but are released for certain purposes without cost; for instance, the INCITS document http://www.unicode.org/L2/L2006/06388-review-incits4.pdf contains the ANS standard. ECMA (another standards body) publishes their standards for free; the equivalent (and AFAIK identical) to the ASCII standard is http://www.ecma- international.org/publications/standards/Ecma-006.htm. I think I'm done here.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-29 08:06 -0400 |
| Message-ID | <op.xe2ukdwh6zenlw@localhost> |
| In reply to | #29936 |
On Mon, 28 Apr 2014 08:43:07 -0400, Alex McDonald <blog@rivadpm.com> wrote: > National standards bodies are reluctant to re-engineer global standards, > and ANSI quite clearly states that it does not develop standards; it > accredits other bodies and adopts their standards. An ISO standard is > generally adopted as an ANSI standard. ANSI is on ISO; > [link] > > ANSI standards are expensive, but are released for certain purposes > without cost; for instance, the INCITS document > [link] contains the ANS > standard. ECMA (another standards body) publishes their standards for > free; the equivalent (and AFAIK identical) to the ASCII standard is > [link] ECMA? ... It's good that they release standards but the quality is debatable. Microsoft wrote a publicly available standard for their FAT12/FAT16. ECMA did too, using Microsoft's own standard. ECMA's standard is completely different. They're nothing alike. They made errors too. I wanted to compare if INCITTS changed anything in the ANSI standard, but I'd need an original ANSI to do so. So, I was going to ask if you had an INCITS link to C89. I had and still have some doubts as to the authenticity and/or accuracy. Some of the things I remember reading and seeing years ago weren't present. But, I decided to let it pass. It might've been in one of the other standards. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-29 19:22 +0100 |
| Message-ID | <ljoql0$7m5$1@dont-email.me> |
| In reply to | #29958 |
on 29/04/2014 13:06:05, "Rod Pemberton" wrote: > On Mon, 28 Apr 2014 08:43:07 -0400, Alex McDonald <blog@rivadpm.com> > wrote: > >> National standards bodies are reluctant to re-engineer global standards, >> and ANSI quite clearly states that it does not develop standards; it >> accredits other bodies and adopts their standards. An ISO standard is >> generally adopted as an ANSI standard. ANSI is on ISO; >> [link] >> >> ANSI standards are expensive, but are released for certain purposes >> without cost; for instance, the INCITS document >> [link] contains the ANS >> standard. ECMA (another standards body) publishes their standards for >> free; the equivalent (and AFAIK identical) to the ASCII standard is >> [link] > > ECMA? ... > It's good that they release standards but the quality is debatable. > > Microsoft wrote a publicly available standard for their FAT12/FAT16. > ECMA did too, using Microsoft's own standard. ECMA's standard is > completely different. They're nothing alike. They made errors too. That happens. The best standards get revised because people use them. Forth 200x for example. > > I wanted to compare if INCITTS changed anything in the ANSI standard, > but I'd need an original ANSI to do so. So, I was going to ask if > you had an INCITS link to C89. I had and still have some doubts as > to the authenticity and/or accuracy. Some of the things I remember > reading and seeing years ago weren't present. But, I decided to let > it pass. It might've been in one of the other standards. > > > Rod Pemberton > INCITS didn't ratify C89 since it had a number of errors. INCITS/ISO/IEC 9899: 1999 colloquially C90 has been withdrawn since it has been superceded. You will find difficuty in finding a free and legal copy.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web