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 | 18 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 4 of 4 — ← Prev page 1 2 3 [4]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2014-05-25 16:44 -0400 |
| Message-ID | <99l4o9tidgqe6etgmidbvmc6u97f1kfm9k@4ax.com> |
| In reply to | #29972 |
On Tue, 29 Apr 2014 19:22:24 +0100, "Alex McDonald" <blog@rivadpm.com> wrote: > 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 Many ANSI standards are very expensive, but *INCITS* are USD60, which is nearly tolerable. And for C in particular (JTC1/SC22) WG14 drafts -- which are actually almost identical to the standard, although not legally guaranteed to be so -- are free-beer. (Also WG21 for C++.) <snip> > > 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. > > C89 was an X3(J11) thus ANSI document X3.159-1989 before the name change. It was then submitted to JTC1/SC22/WG14 which made editorial changes (foreword and such) but no changes to the technical content and adopted it as ISO/IEC 9899:1990 called C90. NCITS and ANSI then adopted C90 to replace (substantively equivalent) C89. After that (now-INCITS) J11 and (SC22) WG14 jointly developed two Technical Corrigenda and one Normative Amendment, and then the new version published as ISO/IEC 9899:1999 called C99 and adopted by INCITS/ANSI; then more corrigenda to C99 followed by a new version 9899:2011 called C11. (During development it was planned for '08 or '09 and called C0x; the rather strained joke became that 0x in C indicates a hex constant, so 11 is still in range.) > 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. C90 was 9899:1990 and has indeed been superceded by C99. Formally C99 has also been superceded by C11, but webstore.ansi.org still has both.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-29 07:54 -0400 |
| Message-ID | <op.xe2t081f6zenlw@localhost> |
| In reply to | #29934 |
On Mon, 28 Apr 2014 07:24:39 -0400, Mark Wills <markwills1970@gmail.com> 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. > > 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. It does. It defines both ASCII and extended ASCII. > The American Standard Code for Information Interchange is a 7-bit *set* > (my term). It's not exclusively a 7-bit standard as you've incorrectly noted here: > A separate standard (see my earlier post) specifies a > standardised method to extend the system into an 8-bit set. The extended ASCII characters are defined as part of the ASCII standard. > A byte may be 8 bits, 7 bits, or 11 bits, or anything else. No. A byte is exactly 8-bits. That's how they originally defined it. This should be available in interviews online. > 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. No one said ASCII defined a byte. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-29 06:06 -0700 |
| Message-ID | <659fa489-e640-4638-a608-e238d7c37b3b@googlegroups.com> |
| In reply to | #29957 |
On Tuesday, 29 April 2014 12:54:34 UTC+1, Rod Pemberton wrote: > No. A byte is exactly 8-bits. That's how they originally defined it. > This should be available in interviews online. You're right. I found this: http://www.bobbemer.com/BYTE.HTM Which makes interesting reading. IBM also standardised on an 8-bit byte, in 1961, under their SPREAD development programme, which led directly to S/360 family of machines. If so, Bob Bemer begs to differ with you: Regarding ASCII being an 8 bit character set, Bob Bemer himself begs to differ with you. From the same page: "That was a little too much progress when presented to the standards group that was to formalize ASCII, so they stopped short for the moment with a 7-bit set, or else an 8-bit set with the upper half left for future work." Full disclosure: The preceding paragraph at the above link does indeed state quite clearly that he (Bemer) defined an *8-bit* character set, however, as can be seen from the snippet posted above, the *standards group* chose to define a 7-bit set. I think that pretty much puts the tin-lid on it as far as I'm concerned. If the title of ANSI X3.4-1986 "Coded Character Sets - 7-Bit American National Standard Code for Information Interchange" is not good enough for you, hopefully the above link is.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-29 19:07 +0100 |
| Message-ID | <ljoppp$ee$1@dont-email.me> |
| In reply to | #29960 |
on 29/04/2014 14:06:34, Mark Wills wrote: > On Tuesday, 29 April 2014 12:54:34 UTC+1, Rod Pemberton wrote: >> No. A byte is exactly 8-bits. That's how they originally defined it. >> This should be available in interviews online. > > You're right. I found this: http://www.bobbemer.com/BYTE.HTM > > Which makes interesting reading. IBM also standardised on an 8-bit > byte, in 1961, under their SPREAD development programme, which led > directly to S/360 family of machines. STRETCH, not SPREAD. ISO 80000-13 defined "byte" as being 8 bits in 2008, over 50 years after it was coined. CDC bytes were 12 bits, but the name was an anachronism. Most architectures referred to addressable units of memory as words.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-28 04:17 -0700 |
| Message-ID | <8160d1e4-2a52-479f-92b2-6053d3399632@googlegroups.com> |
| In reply to | #29901 |
http://www.unicode.org/L2/L2006/06388-review-incits4.pdf Paragraph 1.5: This character set includes control characters for code extension where its 128 characters are insufficient for particular applications. The use of code extension control characters is not defined by this standard. Section 4, Specification of the Coded Character Set The bits of the bit combinations of the 7-bit code are identified by the bits B7 B6 B5 B4 B3 B2 B1 where B7 is the highest order bit... Chapter 4, section 4.1, subsection 3: Code extension control characters: Code extension control characters are used to extend the character set of the code. They may alter the meaning of one or more bit combinations that follow them in the data stream. Procedures for the use of the code extension control characters are specified in ANSI X3.41-1974. Appendix B, section B1.3 In recognition of othese requirements for control and graphic chracters, additional national and international standardization efforts beyond thos provided in this standard are in progress to extend the 7-bit code. The techniques for this extension are provided by ISO 2022-1982 and ANSI X3.41-1974. An example of control function extension is provided in ANSI X3.64-1979. A prime example of graphic chracter extension is provided in ANSI X3.110-1983. See E1, E1.1 where it states that: E1.1 Codes and Code Extension ANSI X3.41-1974, Code Extension Techniques for Use with the *7-Bit* Coded Character Set of American National Standard Code for Information Interchange. This is a general purpose information interchange standard for structuring coded character sets in 7-bit or 8-bit environemtns and for extending the number of characters that can be represented and 128 and 256, respectively.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-29 08:20 -0400 |
| Message-ID | <op.xe2u72jb6zenlw@localhost> |
| In reply to | #29933 |
On Mon, 28 Apr 2014 07:17:09 -0400, Mark Wills <markwills1970@gmail.com> wrote: > http://www.unicode.org/L2/L2006/06388-review-incits4.pdf > > Paragraph 1.5: > This character set includes control characters for code extension where > its 128 characters are insufficient for particular applications. The use > of code extension control characters is not defined by this standard. > > Section 4, Specification of the Coded Character Set > The bits of the bit combinations of the 7-bit code are identified by the > bits B7 B6 B5 B4 B3 B2 B1 where B7 is the highest order bit... > > > Chapter 4, section 4.1, subsection 3: > Code extension control characters: Code extension control characters are > used to extend the character set of the code. They may alter the meaning > of one or more bit combinations that follow them in the data stream. > Procedures for the use of the code extension control characters are > specified in ANSI X3.41-1974. > > Appendix B, section B1.3 > In recognition of othese requirements for control and graphic chracters, > additional national and international standardization efforts beyond > thos provided in this standard are in progress to extend the 7-bit code. > The techniques for this extension are provided by ISO 2022-1982 and ANSI > X3.41-1974. An example of control function extension is provided in ANSI > X3.64-1979. A prime example of graphic chracter extension is provided in > ANSI X3.110-1983. > > > See E1, E1.1 where it states that: > E1.1 Codes and Code Extension > ANSI X3.41-1974, Code Extension Techniques for Use with the *7-Bit* > Coded Character Set of American National Standard Code for Information > Interchange. This is a general purpose information interchange standard > for structuring coded character sets in 7-bit or 8-bit environemtns and > for extending the number of characters that can be represented and 128 > and 256, respectively. > Here, directly from Bob Bemer: "So some folks started thinking about 7-bit characters, but this was ridiculous. ... It seemed reasonable to make a universal 8-bit character set, ... That was a little too much progress when presented to the standards group that was to formalize ASCII, so they stopped short for the moment with a 7-bit set, or else an 8-bit set with the upper half left for future work." Also, "... Dr. Werner Buchholz, the man who DID coin the term 'byte' for an 8-bit grouping." http://bobbemer.com/BYTE.HTM Conclusions: 1) a "byte" was defined to be exactly 8-bits 2) Bob Bemer defined a 8-bit character set 3) ASCII is not exclusively a 7-bit set Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-29 06:09 -0700 |
| Message-ID | <d49d2c94-f120-4daf-89b3-22bbd35af2a1@googlegroups.com> |
| In reply to | #29959 |
On Tuesday, 29 April 2014 13:20:16 UTC+1, Rod Pemberton wrote: > On Mon, 28 Apr 2014 07:17:09 -0400, Mark Wills <markwills1970@gmail.com> > > wrote: > > > > > http://www.unicode.org/L2/L2006/06388-review-incits4.pdf > > > > > > Paragraph 1.5: > > > This character set includes control characters for code extension where > > > its 128 characters are insufficient for particular applications. The use > > > of code extension control characters is not defined by this standard. > > > > > > Section 4, Specification of the Coded Character Set > > > The bits of the bit combinations of the 7-bit code are identified by the > > > bits B7 B6 B5 B4 B3 B2 B1 where B7 is the highest order bit... > > > > > > > > > Chapter 4, section 4.1, subsection 3: > > > Code extension control characters: Code extension control characters are > > > used to extend the character set of the code. They may alter the meaning > > > of one or more bit combinations that follow them in the data stream. > > > Procedures for the use of the code extension control characters are > > > specified in ANSI X3.41-1974. > > > > > > Appendix B, section B1.3 > > > In recognition of othese requirements for control and graphic chracters, > > > additional national and international standardization efforts beyond > > > thos provided in this standard are in progress to extend the 7-bit code. > > > The techniques for this extension are provided by ISO 2022-1982 and ANSI > > > X3.41-1974. An example of control function extension is provided in ANSI > > > X3.64-1979. A prime example of graphic chracter extension is provided in > > > ANSI X3.110-1983. > > > > > > > > > See E1, E1.1 where it states that: > > > E1.1 Codes and Code Extension > > > ANSI X3.41-1974, Code Extension Techniques for Use with the *7-Bit* > > > Coded Character Set of American National Standard Code for Information > > > Interchange. This is a general purpose information interchange standard > > > for structuring coded character sets in 7-bit or 8-bit environemtns and > > > for extending the number of characters that can be represented and 128 > > > and 256, respectively. > > > > > > > Here, directly from Bob Bemer: > > > > "So some folks started thinking about 7-bit characters, > > but this was ridiculous. ... It seemed reasonable to > > make a universal 8-bit character set, ... That was a > > little too much progress when presented to the standards > > group that was to formalize ASCII, so they stopped short > > for the moment with a 7-bit set, or else an 8-bit set > > with the upper half left for future work." > > > > Also, > > > > "... Dr. Werner Buchholz, the man who DID coin the term > > 'byte' for an 8-bit grouping." > > > > http://bobbemer.com/BYTE.HTM > > > > Conclusions: > > 1) a "byte" was defined to be exactly 8-bits > > 2) Bob Bemer defined a 8-bit character set > > 3) ASCII is not exclusively a 7-bit set > > > > > > Rod Pemberton Ha ha! Hilarious! We cite the same sources, but arrive at different conculsions (at least, wrt to ASCII bit length!). Ah well. I'd still buy you a beer!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothaver.cqm> |
|---|---|
| Date | 2014-04-21 20:39 -0400 |
| Message-ID | <op.xeoz3tu00cxrw8@localhost> |
| In reply to | #29742 |
On Sun, 20 Apr 2014 17:02:08 -0400, <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) > > Now if we were talking about 'octet-code', that might be different... > Sorry, I overlooked your post. See my reply below rickman for the history of a byte. RP
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-18 22:24 -1000 |
| Message-ID | <p8qdnVSWQZA-r8_OnZ2dnUVZ_rGdnZ2d@supernews.com> |
| In reply to | #29713 |
On 4/18/14 9:08 PM, Rod Pemberton wrote: > On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> wrote: > >> I was hoping I could get some recommendations on a Forth system that I >> can embed in C. >> >> What I'm currently looking for is >> >> - Able to produce Forth bytecode that can be transmitted over the >> network and executed there > > I'm not sure of any that can produce bytecode ... That would dramatically > limit the number of definable Forth words or dictionary size, although > Forths which use bytecode probably do exist. LOL, there have been bytecode Forths ever since the first MacForth (by Don Colburn) in 1984. MPE and FORTH, Inc. have both done extensive work with bytecode Forths, including a major joint project in the 90's. The standard approach, used by many languages, is to code the most common 127 functions in one-byte codes, and use the high bit to signal that there is a 2nd byte representing more functions. It's not terribly hard to implement such a system with very respectable performance. 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-19 05:02 -0400 |
| Message-ID | <op.xej3ee1i6zenlw@localhost> |
| In reply to | #29715 |
On Sat, 19 Apr 2014 04:24:01 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > On 4/18/14 9:08 PM, Rod Pemberton wrote: >> On Fri, 18 Apr 2014 09:46:48 -0400, <cslarsen@gmail.com> wrote: >>> - Able to produce Forth bytecode that can be transmitted over the >>> network and executed there >> >> I'm not sure of any that can produce bytecode ... That would >> dramatically limit the number of definable Forth words or dictionary >> size, although Forths which use bytecode probably do exist. > > LOL, there have been bytecode Forths ever since the first MacForth > (by Don Colburn) in 1984. You're implying I said none exist. I didn't. Re-read please. > MPE and FORTH, Inc. have both done extensive work > with bytecode Forths, including a major joint project in the 90's. That's nice to know. Are they open-source? If not, then they don't help the OP. > The standard approach, used by many languages, is to code the most > common 127 functions in one-byte codes, and use the high bit to signal > that there is a 2nd byte representing more functions. Well, that wouldn't truly be bytecoded then, would it? I.e., it uses more than one byte per instruction for some instructions. Technically, it's variable-length instruction. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-19 01:43 -0700 |
| Message-ID | <7x7g6laevm.fsf@ruckus.brouhaha.com> |
| In reply to | #29701 |
cslarsen@gmail.com writes: > - Able to embed as an execution engine in C or C++ Do you mean the C extension only has to run bytecode from an offline compiler? You might look at retroforth.org - it's actually 32-bit code but the low level interpreter is very simple, and you can easily modify it to call your C functions. Its Forth dialect is nonstandard but interesting. If you want a higher level extension language that's somewhat more resource-hungry than Forth but still small by today's standards, look at Lua (lua.org).
[toc] | [prev] | [next] | [standalone]
| From | andraszsoter@gmail.com |
|---|---|
| Date | 2014-04-21 09:30 -0700 |
| Message-ID | <b54a8ad7-6df4-4b4d-b67e-5dcd61f7d3bd@googlegroups.com> |
| In reply to | #29701 |
I am reluctant to recommend my latest pet project because it still looks like a science project experiment, but I am convinced that you can do with it what you describe here. http://forth.teleonomix.com/efci/ Andras On Friday, April 18, 2014 9:46:48 AM UTC-4, csla...@gmail.com wrote: > Hi, > > > > I was hoping I could get some recommendations on a Forth system that I can embed in C. > > > > What I'm currently looking for is > > > > - Able to produce Forth bytecode that can be transmitted over the network and executed there > > - Able to embed as an execution engine in C or C++ > > - Able to have Forth words call C functions (no need for a full-blown FFI, if I can modify the source and translate the call to C, that'd be fine) > > - Preferrably have a small memory footprint > > - It must be open source > > > > Bonus points if > > > > - Its codebase is small and readable > > - I'm able to control execution from C, e.g. select number of cycles to run before going back to C (this is to be able to halt Forth programs that loop endlessly) > > > > This is for a thesis project on networking, so I think Forth would fit very nicely, even though I'm only going to run it in software. > > > > About calling C functions: I'm going to extract data from ethernet or IP packets. I already have those in C, so what I'm thinking of is a way to have this Forth call into C and get data back on the stack. I don't need or want a full FFI; I'm going to compile them in statically (for instance by modifying the Forth code). > > > > I've been looking at gforth, but to me it looks to be a bit too big. I've looked at pforth, but that didn't compile cleanly on my system so I got cold feet. Currently I'm looking into PFE and possibly 4th. > > > > What I'd really like to avoid is rolling my own Forth. I've done that before, but right now I need something that is robust. > > > > Also I probably *don't* need a *fully* ANS compliant Forth. I'm only going to execute some simple IF statements and then inspect return values to the C environment from the top of the stack. > > > > If anyone can give me pointers, I'd be very happy. > > > > Regards, > > > > Christian
[toc] | [prev] | [next] | [standalone]
| From | "VisualForth.com" <babruehl@gmail.com> |
|---|---|
| Date | 2014-05-25 15:31 -0700 |
| Message-ID | <503ba439-8d6f-4828-a274-aa4c065bf098@googlegroups.com> |
| In reply to | #29701 |
On Friday, April 18, 2014 9:46:48 AM UTC-4, csla...@gmail.com wrote: > > What I'm currently looking for is > - Able to produce Forth bytecode that can be transmitted over the network and executed there > - Able to embed as an execution engine in C or C++ > - Able to have Forth words call C functions (no need for a full-blown FFI, if I can modify the source and translate the call to C, that'd be fine) > - Preferrably have a small memory footprint > ... > What I'd really like to avoid is rolling my own Forth. I've done that before, but right now I need something that is robust. Google for "Open Terminal Architecture" (OTA)and you will find it. A Byte-Code Forth which is a Byte-Code C at the same time. Developed by our famous Forth factories. It is robust, it is ISO/IEC 20060, and you find the specifications at Amazon. There it says: "The overall architecture of the Open Terminal Architecture is described in Appendix F, "System Architecture," and is based on a Virtual Machine (VM) that can be programmed using high-level languages such as Forth or C" "This International Standard describes a set of functions to be implemented in terminals in terms of instructions for a Virtual Machine. With these functions the application programmer is able to generate application software that is compact, portable and certifiable ..." Distributed through American National Standards Institute (ANSI) (August 23, 2007 And there is more than a specification! OTA exists and has been field tested successfully. > - It must be open source I don't know about this. Ask Elizabeth. I am sure the time has come to make it open source.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-25 16:54 -1000 |
| Message-ID | <d9CdnYupFO93MR_OnZ2dnUVZ_qudnZ2d@supernews.com> |
| In reply to | #30721 |
On 5/25/14 12:31 PM, VisualForth.com wrote: > On Friday, April 18, 2014 9:46:48 AM UTC-4, csla...@gmail.com wrote: >> >> What I'm currently looking for is >> - Able to produce Forth bytecode that can be transmitted over the network and executed there >> - Able to embed as an execution engine in C or C++ >> - Able to have Forth words call C functions (no need for a full-blown FFI, if I can modify the source and translate the call to C, that'd be fine) >> - Preferrably have a small memory footprint >> ... >> What I'd really like to avoid is rolling my own Forth. I've done that before, but right now I need something that is robust. > > Google for "Open Terminal Architecture" (OTA)and you will find it. > A Byte-Code Forth which is a Byte-Code C at the same time. > Developed by our famous Forth factories. > > It is robust, it is ISO/IEC 20060, and you find the specifications at Amazon. > There it says: > "The overall architecture of the Open Terminal Architecture is described in Appendix F, "System Architecture," and is based on a Virtual Machine (VM) that can be programmed using high-level languages such as Forth or C" > > "This International Standard describes a set of functions to be implemented in terminals in terms of instructions for a Virtual Machine. With these functions the application programmer is able to generate application software that is compact, portable and certifiable ..." > Distributed through American National Standards Institute (ANSI) (August 23, 2007 > > And there is more than a specification! > > OTA exists and has been field tested successfully. > >> - It must be open source > I don't know about this. Ask Elizabeth. > I am sure the time has come to make it open source. Whew, a lot of issues. To begin with, OTA is an application-oriented language for programming smart-card terminals, not a general-purpose system. The user-level commands include a lot of Forth, but mostly deal with smart-card issues. Second, the smart-card industry is understandably incredibly security conscious. They will not encourage random engineers to start developing their own smart-card terminals! Third, although the documentation has been published, I am pretty sure the code has not. Although it built on underlying technology from MPE and FORTH, Inc., it was developed under contract and neither of us "owns" it or has the ability to control its release status. And that's only a start. But, by all means, read the document. It will give you a lot of hints for your own work. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-25 22:29 -0700 |
| Message-ID | <7xoaylcdkz.fsf@ruckus.brouhaha.com> |
| In reply to | #30732 |
"Elizabeth D. Rather" <erather@forth.com> writes: > To begin with, OTA is an application-oriented language for programming > smart-card terminals..., although the documentation has been > published, I am pretty sure the code has not... But, by all means, > read the document. It will give you a lot of hints for your own work. Is the document online anywhere? I found a Dr Dobbs article http://www.drdobbs.com/open-source/smart-cards-and-the-open-terminal-archit/184410748 which has some example code, but the only source I saw for the complete spec seemed to be a very expensive ISO document. There is a preview here showing the table of contents: http://webstore.iec.ch/preview/info_isoiec20060%7Bed2.0%7Den.pdf The crypto functions could use an update but the rest looks still worth studying.
[toc] | [prev] | [next] | [standalone]
| From | "VisualForth.com" <babruehl@gmail.com> |
|---|---|
| Date | 2014-05-26 10:45 -0700 |
| Message-ID | <ba7a991b-6c3b-4edb-94a4-5e6de816dbb9@googlegroups.com> |
| In reply to | #30732 |
On Sunday, May 25, 2014 10:54:33 PM UTC-4, Elizabeth D. Rather wrote: > On 5/25/14 12:31 PM, VisualForth.com wrote: > > On Friday, April 18, 2014 9:46:48 AM UTC-4, csla...@gmail.com wrote: > >> What I'm currently looking for is > >> - Able to produce Forth bytecode that can be transmitted over the network and executed there > >> - Able to embed as an execution engine in C or C++ > >> - Able to have Forth words call C functions (no need for a full-blown FFI, if I can modify the source and translate the call to C, that'd be fine) > >> What I'd really like to avoid is rolling my own Forth. I've done that before, but right now I need something that is robust. > > > Google for "Open Terminal Architecture" (OTA)and you will find it. > > A Byte-Code Forth which is a Byte-Code C at the same time. > > I am sure the time has come to make it open source. > Whew, a lot of issues. To begin with, OTA is an application-oriented > language for programming smart-card terminals, not a general-purpose > system. The user-level commands include a lot of Forth, but mostly deal > with smart-card issues. I studied the OTA in 2000 when I was working for EuroSignCard, Luxembourg. The OTA consists of a VM which is byte-code-Forth, somehow comparable to the OpenBootPROM, but suited for microprocessors with memory constraints. > Second, the smart-card industry is understandably incredibly security > conscious. They will not encourage random engineers to start developing > their own smart-card terminals! I myself was member of the smart-card industry, and I think this request for a Forth producing byte-code that can be transmitted over the network and executed there is not intended to develop smart-card terminals. And I guess this request is not from a random engineer. By the way, often important work is done by random engineers. As a "random engineer" I developed interfaces for smart cards - the German "Geldkarte" and the Austrian EuroPay bank card as a Siemens contractor. My firmware was certified by the ZKA in Bonn, Germany and the EuroPay in Vienna, Austria. > Third, although the documentation has been published, I am pretty sure > the code has not. Although it built on underlying technology from MPE > and FORTH, Inc., it was developed under contract and neither of us > "owns" it or has the ability to control its release status. This sounds a little bit like Chuck Moore's iTv - Chuck did a great work, but nobody is allowed to use it. I am sure the OTA case is different. The OTA is a standard now, and I am sure it is allowed to use this standard. What else should a standard be good for? > And that's only a start. But, by all means, read the document. It will > give you a lot of hints for your own work. This looks like the suggestion to invent the wheel again. Why isn't it possible to generally use this byte-code, developed for OTA? That would open the market for Forth like it did for Java. Several times the OTA documents are comparing the OTA byte-code with Java. Forth has been chosen because it is superior to Java for this application.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-26 09:39 -1000 |
| Message-ID | <nOOdnWoLMoESBR7OnZ2dnUVZ_sqdnZ2d@supernews.com> |
| In reply to | #30758 |
On 5/26/14 7:45 AM, VisualForth.com wrote: > On Sunday, May 25, 2014 10:54:33 PM UTC-4, Elizabeth D. Rather wrote: >> On 5/25/14 12:31 PM, VisualForth.com wrote: >>> On Friday, April 18, 2014 9:46:48 AM UTC-4, csla...@gmail.com wrote: >>>> What I'm currently looking for is >>>> - Able to produce Forth bytecode that can be transmitted over the network and executed there >>>> - Able to embed as an execution engine in C or C++ >>>> - Able to have Forth words call C functions (no need for a full-blown FFI, if I can modify the source and translate the call to C, that'd be fine) >>>> What I'd really like to avoid is rolling my own Forth. I've done that before, but right now I need something that is robust. >> >>> Google for "Open Terminal Architecture" (OTA)and you will find it. >>> A Byte-Code Forth which is a Byte-Code C at the same time. >>> I am sure the time has come to make it open source. > >> Whew, a lot of issues. To begin with, OTA is an application-oriented >> language for programming smart-card terminals, not a general-purpose >> system. The user-level commands include a lot of Forth, but mostly deal >> with smart-card issues. > > I studied the OTA in 2000 when I was working for EuroSignCard, Luxembourg. > The OTA consists of a VM which is byte-code-Forth, somehow comparable to the OpenBootPROM, but suited for microprocessors with memory constraints. > >> Second, the smart-card industry is understandably incredibly security >> conscious. They will not encourage random engineers to start developing >> their own smart-card terminals! > > I myself was member of the smart-card industry, and I think this request for > a Forth producing byte-code that can be transmitted over the network and executed there is not intended to develop smart-card terminals. Actually, it was. The byte code is the program, which is executed on a terminal. The intent was to be able to write portable terminal programs that would run on different vendors' terminals. The banks thought this was a great idea, the terminal vendors not so much. They basically vetoed it. > And I guess this request is not from a random engineer. > By the way, often important work is done by random engineers. > As a "random engineer" I developed interfaces for smart cards - the German "Geldkarte" and the Austrian EuroPay bank card as a Siemens contractor. My firmware was certified by the ZKA in Bonn, Germany and the EuroPay in Vienna, Austria. > >> Third, although the documentation has been published, I am pretty sure >> the code has not. Although it built on underlying technology from MPE >> and FORTH, Inc., it was developed under contract and neither of us >> "owns" it or has the ability to control its release status. > > This sounds a little bit like Chuck Moore's iTv - Chuck did a great work, but nobody is allowed to use it. > > I am sure the OTA case is different. The OTA is a standard now, and I am sure it is allowed to use this standard. What else should a standard be good for? Yes, OTA is a standard. You are welcome to start from scratch and develop something compliant. But the existing working code for about 10 different terminals is proprietary and you will never see it. >> And that's only a start. But, by all means, read the document. It will >> give you a lot of hints for your own work. > > This looks like the suggestion to invent the wheel again. > Why isn't it possible to generally use this byte-code, developed for OTA? > That would open the market for Forth like it did for Java. Talk to Stephen, who has a much more generalized version of the system. > Several times the OTA documents are comparing the OTA byte-code with Java. > Forth has been chosen because it is superior to Java for this application. > Yes, but technical superiority is no match for marketing power. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-25 16:30 -0700 |
| Message-ID | <7x4n0da12c.fsf@ruckus.brouhaha.com> |
| In reply to | #29701 |
cslarsen@gmail.com writes: > This is for a thesis project on networking, so I think Forth would fit > very nicely, even though I'm only going to run it in software. > About calling C functions: I'm going to extract data from ethernet or > IP packets. Maybe you want to look at the Berkeley Packet Filter. http://blog.cloudflare.com/bpf-the-forgotten-bytecode
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web