Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #35875 > unrolled thread

Expected BASE-LINE for Embedded Controllers

Back to article view | Back to comp.lang.forth

Contents

  Expected BASE-LINE for Embedded Controllers Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-18 11:58 +0000
    Re: Expected BASE-LINE for Embedded Controllers Matthias Trute <matthias.trute@gmail.com> - 2015-01-18 04:55 -0800
      Re: Expected BASE-LINE for Embedded Controllers Mikael Nordman <oh2aun@gmail.com> - 2015-01-18 10:20 -0800
      Re: Expected BASE-LINE for Embedded Controllers visualforth@rocketmail.com - 2015-01-20 10:45 -0800
        Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 12:34 -1000
          Re: Expected BASE-LINE for Embedded Controllers visualforth@rocketmail.com - 2015-01-20 16:40 -0800
    Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-18 22:27 +0100
      Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-18 13:45 -1000
        Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-19 18:22 +0000
      Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-19 12:06 +0100
        Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-19 18:47 +0000
          Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-19 11:22 -1000
            Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-20 11:54 +0000
          Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-20 09:49 +0100
        Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-19 20:27 +0100
        Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 11:04 -0800
          Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-20 11:33 -0800
          Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 23:30 +0100
            Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 14:41 -0800
              Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 00:40 +0100
                Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 15:53 -0800
                  Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 01:41 +0100
                    Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 15:38 -1000
                    Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:08 -0800
                      Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-23 16:10 +0000
              Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 15:25 -1000
            Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-21 10:40 +0000
    Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-19 12:00 +0100
    Re: Expected BASE-LINE for Embedded Controllers Mikael Nordman <oh2aun@gmail.com> - 2015-01-21 00:04 -0800
      Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-21 11:53 +0100
      Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-21 03:02 -0800
      Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-21 03:07 -0800
        Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-22 15:50 +0100
          Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-22 16:39 +0000
          Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:13 -0800
            Re: Expected BASE-LINE for Embedded Controllers stephen@mpeforth.com (Stephen Pelc) - 2015-01-23 11:19 +0000
              Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-23 16:12 +0000
            Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-23 16:42 +0000
              Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-24 01:53 -0800
                Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-24 15:33 +0100
                Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-25 15:48 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#35931

Bernd Paysan <bernd.paysan@gmx.de> writes:
> No, we know how to implement SP@, we don't need someone telling us
> that it can't be done.

I didn't say it couldn't be done--it just generates messier code, as you
demonstrated.  There are other ways to multitask that can be preferable,
depending on the cpu.

>> I like the idea of standardized multitasking words
> We like that, too, but it is not the right thing for a base-line
> wordset for embedded controllers, which is the topic *here*.

Why should the multitasking words for controllers not follow the same
standard?  It's not as if the standard is going to specify anything
comparably heavyweight to Posix threads.  The GA144 is as "embedded" as
it gets, and Polyforth and Eforth both run on it, though I don't know if
the Eforth port supports multitasking.

[toc] | [prev] | [next] | [standalone]

#35933

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> No, we know how to implement SP@, we don't need someone telling us
>> that it can't be done.
> 
> I didn't say it couldn't be done--it just generates messier code, as you
> demonstrated.

Oh, come on.  Of course saving the registers means to emit code to save the 
registers.  On most CPUs with a single core, that's necessary to switch 
tasks.

You might be thinking of a SPARC with its rotating register window, which 
could be used to do a quick task switch without saving the registers.  Feel 
free to optimize stuff with non-standard constructs; this doesn't imply that 
the standard has to add a layer of abstraction.

> There are other ways to multitask that can be preferable,
> depending on the cpu.

I want to remind you that one essential design principle of Forth is to not 
abstract just for the sake of abstraction, and to speculate about things 
which you haven't yet seen in practice.  And that you are off topic here: 
The topic is what's a suitable base-line for embedded controllers; please 
read the subject line.

Systems big enough that they come with a multitasker by default are out of 
scope here.

>>> I like the idea of standardized multitasking words
>> We like that, too, but it is not the right thing for a base-line
>> wordset for embedded controllers, which is the topic *here*.
> 
> Why should the multitasking words for controllers not follow the same
> standard?

I've already written that: You don't want to have the full-blown thing, one 
task in the background, only switched to during KEY? usually does the job.

> It's not as if the standard is going to specify anything
> comparably heavyweight to Posix threads.

Ah, the "big end" of Forth multitasking certainly is using POSIX threads, so 
it at least has to take that into account.

> The GA144 is as "embedded" as
> it gets, and Polyforth and Eforth both run on it, though I don't know if
> the Eforth port supports multitasking.

The Polyforth/Eforth on GA144 are somewhat odd efforts: they just use some 
of the tiny cores to emulate a single core CPU.  The parallelism of GA144 is 
only available to ColorForth.

If they come with a multitasker, it's the traditional PAUSE multitasker, and 
it won't parallelize the tasks onto more GA144 cores, because those ports 
can only run on the few cores which have access to the external memory.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

#35935

On 1/20/15 2:41 PM, Bernd Paysan wrote:
> Paul Rubin wrote:
...
>> There are other ways to multitask that can be preferable,
>> depending on the cpu.
>
> I want to remind you that one essential design principle of Forth is to not
> abstract just for the sake of abstraction, and to speculate about things
> which you haven't yet seen in practice.  And that you are off topic here:
> The topic is what's a suitable base-line for embedded controllers; please
> read the subject line.
>
> Systems big enough that they come with a multitasker by default are out of
> scope here.

SwiftX supports multitasking on even the smallest microcontrollers. Over 
30 years ago we were running many tasks on small 8051s (with 
microFORTH). However, having a fast, light-weight multitasker requires 
some design considerations that folks accustomed to conventional 
architectures are uncomfortable with. This is one of the reasons that 
the community has found it difficult to standardize multiasker words.

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]

#35960

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Oh, come on.  Of course saving the registers means to emit code to save the 
> registers.  On most CPUs with a single core, that's necessary to switch 
> tasks.

The difference is that a general multitasker can save the registers any
way it wants, while SP@ (barring ugly hacks) has to save them on the
data stack.  That decreases flexibility, e.g. with cpus that can save a
set of registers in a single instruction.  For that matter, shuffling
the registers to the data stack apparently took considerable
implementation effort in VFX.  Easier to use a save/restore mechanism
that doesn't need such complexity.  That also makes it easier to
implement multitasking by running Forth under a non-Forth RTOS if that's
desired.  There are some very light and simple ones around.

> You might be thinking of a SPARC with its rotating register window,

I wasn't thinking of register windows particularly.  But some cpu's can
save the registers in one instruction or even (Parallax Propeller) have
built-in multitasking and multiprocessing.

As another example, I've mentioned the Beaglebone real-time coprocessor
as a promising Forth target in some other posts.  It has 32 registers so
a reasonable way to implement a two-task multitasker with very low
switching latency could be to just dedicate a dozen or so registers to
the background task, and put that task's stacks in those registers, with
the compiler knowing which task was which.  So there would be no need to
save the registers as they'd be left alone between switches.  Switching
at the Forth level would just be an F18-like coroutine jump that would
compile down to a simple jump in the case where the compiler tracked
the stack contents.

Come to think of it, for that very simple case, EX (coroutine jump in
Colorforth terminology, http://www.colorforth.com/inst.htm ) might be
enough by itself.  The background task would share the main stack with
the foreground, using a few ALLOTted cells or variables to remember what
it was doing between calls, so it would leave the main stack undisturbed
from the perspective of the foreground task.

> this doesn't imply that the standard has to add a layer of
> abstraction.

The idea of a standard is to abstract over implementations.  So in this
case it should look at the end goal (lightweight multitasking), consider
all the reasonable implementation techniques for that goal, and then
specify an interface that's consistent with existing Forth practice and
can be implemented with any of those techniques.

> I want to remind you that one essential design principle of Forth is
> to not abstract just for the sake of abstraction, and to speculate
> about things which you haven't yet seen in practice.  

I've certainly seen multitaskers in practice that don't rely on anything
as deeply tangled in the interpreter implementation as SP@.  Consider
your mention of Forth multitaskers using Posix threads.

Particularly, I've always found it useful when coding for an embedded
target to also be able to run it on a PC for development/debugging or
for when the target hardware isn't available.  The code can't always be
100% identical, but minimizing the difference between the embedded and
PC versions is worth some effort.  So the word sets should be similar or
identical if possible.

>> Why should the multitasking words for controllers not follow the same
>> standard?
> I've already written that: You don't want to have the full-blown
> thing, one task in the background, only switched to during KEY?
> usually does the job.

Yes, I saw that, but I didn't (and still don't) see why the multitasking
words can't be designed such that a minimal implementation handles the
two-task case perfectly well.  However, Elizabeth has since posted that
the reason it's not standardized is that implementers have never been
able to agree on what's the right set of words, which is something you
hadn't explained.  

So maybe there are serious technical dilemmas or maybe it's just the
usual bikeshedding paralysis.  Either way, it sounds like a reasonable
attempt was made and it failed.  That's a more useful explanation than
"you don't want to have the full-blown thing" and it shows that other
people had the same desire and (at least for a while) saw it as
practical.

> Ah, the "big end" of Forth multitasking certainly is using POSIX
> threads, so it at least has to take that into account.

It's fine to write the standard in a way that makes sure POSIX threads
are a usable implementation approach.  It would be un-Forthlike for the
standard to *require* Forth multitaskers to have anything like the
complexity that POSIX thread implementations need.

[toc] | [prev] | [next] | [standalone]

#35973

In article <87r3um7hvt.fsf@jester.gateway.sonic.net>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Oh, come on.  Of course saving the registers means to emit code to save the
>> registers.  On most CPUs with a single core, that's necessary to switch
>> tasks.
>
>The difference is that a general multitasker can save the registers any
>way it wants, while SP@ (barring ugly hacks) has to save them on the
>data stack.  That decreases flexibility, e.g. with cpus that can save a
>set of registers in a single instruction.  For that matter, shuffling
>the registers to the data stack apparently took considerable
>implementation effort in VFX.  Easier to use a save/restore mechanism
>that doesn't need such complexity.  That also makes it easier to
>implement multitasking by running Forth under a non-Forth RTOS if that's
>desired.  There are some very light and simple ones around.

That's right. A Linux preemptive multitasker is one screen.
A cooperative multitasker is two screens.

If you use high level code you need not think about saving registers.
Inasfar that is needed it is implicit in calling a Forth word.
The most straightforward technique is:
   Save the program counter (or interpreter counter)
   save data stack pointer (and user pointer, that may be all) on the
   return stack.
   switch the return stack
   restore data stack pointer (and what not).
   at the end restore the program counter (or interpreter counter)

This last action continues the task that was abandonned/

So you don't store on the data stack during task switching.
You need not be aware of any registers that you're not aware off
during normal Forth programming.

This is the typical code for a simplistic task switch.
[Normally one would also save a user pointer, but the
user area in this particular Forth (ciforth) is coupled
to the return stack.]

: THIS TASK-POINTER @ ;
: PAUSE-COT
   DSP@ >R RSP@ THIS !   NEXT-TASK   THIS @ RSP! R> DSP! ;

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]

#35934

On 1/20/15 12:41 PM, Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> SP@/RP@/SP!/RP! are these tools, defining a complete multitasking wordset
>> that works well from medium to large systems is overkill for the tiny
>> systems.
>
> Another example where SP@ etc can get in the way, is if you have a
> VFX-like host-side compiler that places a lot of the target's stack
> items in registers.  So the task switcher would save the registers like
> in a conventional OS, and exposing SP@ etc. to the target would make
> things messy.  It seems ok to let the switcher use carnal knowledge.
>
> When I mentioned an FPGA processor I wasn't thinking of the tiny
> b16-like category, but maybe something more like the J1.
>
> I like the idea of standardized multitasking words, so that programs
> that use them can be portable (or at least more portable than they are
> now).
>

That assumes we can standardize a multitasking model, which we've never 
even come close to in past attempts.

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]

#35944

In article <m9mksr$n78$1@dont-email.me>,
Bernd Paysan  <bernd.paysan@gmx.de> wrote:
<SNIP>
>
>SP@/RP@/SP!/RP! are these tools, defining a complete multitasking wordset
>that works well from medium to large systems is overkill for the tiny
>systems.

It is not sufficient. Apart from DSP@ DSP! RSP@ RSP! you need
an UP@ UP! (for user variables), a TASK-SIZE or word to clone
a task area. Still then you need to build in carnal knowledge
about whether stack grow up or down. If you count everything in
the "portable" multi-tasking only works for a family of Forth's
that have the same implementation model.

E.g. the library of ciforth contains a minimalistic multi-tasker. It
works on ciforth's including a medium embedded ciforth system like the
Renesas. There is the design decision in ciforth to have the whole
block (stack and tib) cloned, with distance between bottoms of stack
preserved. With other memory maps. this could look dramatically
different.

>
>--
>Bernd Paysan


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]

#35897

> Special Words: 
> Some special words will have to be added for controllers FLASH and IO 
> handling. These will be underlying machine specific and are therefore not 
> specified in this list.

For Flash environments switching back to <BUILDS DOES> without standard action and one time DOES>able only and CREATE with standard action, but not changeable with DOES> while compiling into Flash seem reasonable to be able to perform compilation without heavy caching or the need for erase cycles which are sometimes not available (e.g. Flash block sizes > available RAM).

Matthias

[toc] | [prev] | [next] | [standalone]

#35939

On Sunday, January 18, 2015 at 1:58:18 PM UTC+2, Paul E Bennett wrote:
> The following 71 words are suggested at this stage. 
> 
> Words for inclusion:
> Memory Access:-
> HERE C@ C! @ , C, ALIGN ALIGNED CELL+ CELLS CALIGN  CALIGNED CHAR+ CHARS 
> ! ' [']

Are CALIGN and CALIGNED really needed in a embedded environment ?
Usually these align to one anyway.

> Arithmetic:-
> + - 2* * / 2/ MOD */MOD UM*

Most of my embedded applications use unsigned math so I would replace 
/ and MOD with UM/MOD and replace */MOD with UM/*MOD
The signed variants can be built from the unsigned ones if needed.

[toc] | [prev] | [next] | [standalone]

#35946

> Are CALIGN and CALIGNED really needed in a embedded environment ?
> Usually these align to one anyway.

Align is for the cell size, and that means 32 Bits on ARM Cortex M. Calign can be used after c, to align to the next opcode boundary, 16 Bits, altough I may have choosen a misleading name.

> Most of my embedded applications use unsigned math so I would replace 
> / and MOD with UM/MOD and replace */MOD with UM/*MOD
> The signed variants can be built from the unsigned ones if needed.

Me, too. Unsigned should always be available in my opinion, signed can be loaded upon.

Matthias

[toc] | [prev] | [next] | [standalone]

#35948

On Wednesday, 21 January 2015 08:04:13 UTC, Mikael Nordman  wrote:
> On Sunday, January 18, 2015 at 1:58:18 PM UTC+2, Paul E Bennett wrote:
> > The following 71 words are suggested at this stage. 
> > 
> > Words for inclusion:
> > Memory Access:-
> > HERE C@ C! @ , C, ALIGN ALIGNED CELL+ CELLS CALIGN  CALIGNED CHAR+ CHARS 
> > ! ' [']
> 
> Are CALIGN and CALIGNED really needed in a embedded environment ?
> Usually these align to one anyway.
> 
> > Arithmetic:-
> > + - 2* * / 2/ MOD */MOD UM*
> 
> Most of my embedded applications use unsigned math so I would replace 
> / and MOD with UM/MOD and replace */MOD with UM/*MOD
> The signed variants can be built from the unsigned ones if needed.

Useful comments. Thanks.

I think the standard should also explicitly standardise on 8 bit bytes.

[toc] | [prev] | [next] | [standalone]

#35949

On Wednesday, 21 January 2015 08:04:13 UTC, Mikael Nordman  wrote:
> Are CALIGN and CALIGNED really needed in a embedded environment ?
> Usually these align to one anyway.

Agree. If the standard can specify an 8 bit byte as the 'atom' (which is
the norm).

[toc] | [prev] | [next] | [standalone]

#35958

Mark Wills wrote:

> On Wednesday, 21 January 2015 08:04:13 UTC, Mikael Nordman  wrote:
>> Are CALIGN and CALIGNED really needed in a embedded environment ?
>> Usually these align to one anyway.
> 
> Agree. If the standard can specify an 8 bit byte as the 'atom' (which is
> the norm).

Anton is planning to do so, at least 1 CHARS = 1 (so CHARS and friends can 
go).  This still allows word-addressed systems (1 char is then just more 
than 8 bits), and systems with 16 bit chars on byte-addressed machines 
probably need to multiply their addresses by 2 before using them - that is 
somewhat inconvenient.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

#35959

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Mark Wills wrote:
>
>> On Wednesday, 21 January 2015 08:04:13 UTC, Mikael Nordman  wrote:
>>> Are CALIGN and CALIGNED really needed in a embedded environment ?
>>> Usually these align to one anyway.
>> 
>> Agree. If the standard can specify an 8 bit byte as the 'atom' (which is
>> the norm).
>
>Anton is planning to do so, at least 1 CHARS = 1 (so CHARS and friends can 
>go).  This still allows word-addressed systems (1 char is then just more 
>than 8 bits), and systems with 16 bit chars on byte-addressed machines 
>probably need to multiply their addresses by 2 before using them - that is 
>somewhat inconvenient.

I know of two such systems, and both were done that way to experiment
with 1 chars != 1, and are not really intended for production; one of
them is JaxForth and is abandoned AFAIK, the other is a recent system
by Peter Knaggs written in Java/C#.  The latter implementation has
difficulties representing addresses anyway, and 1 chars = 1 would be
just as easy to implement as 1 chars = 2.

I also heard of an embedded system with 16-bit address units and
32-bit chars.  If we standardize on 1 chars = 1, the simplest way
forward for such a system would be to declare an environmental
restriction of having a non-standard char size; alternatively, one
could try to change the char size to 16 bits, or the address unit size
to 32 bits.  I don't know enough about the system to make any
recommendation among these options.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#35961

Bernd Paysan <bernd.paysan@gmx.de> writes:
> at least 1 CHARS = 1 (so CHARS and friends can go).... 

That sounds like a declaration of ignoring Unicode.  From a Forth
perspective, maybe that's a good thing, but it seems a bit
anachronistic.

[toc] | [prev] | [next] | [standalone]

#35969

On Thu, 22 Jan 2015 11:13:18 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> at least 1 CHARS = 1 (so CHARS and friends can go).... 
>
>That sounds like a declaration of ignoring Unicode.  From a Forth
>perspective, maybe that's a good thing, but it seems a bit
>anachronistic.

No, no, no. In Forth-200x terminology, what used to be called
a character is now called a primitive character, or pchar for
short. UTF-8 is built from one or more pchars and UTF-16 can be
handled by 1 CHARS = 2 (the trad solution) or by 1 CHARS = 1 and
use of the wide character extensions.

There are enough comms protocols defined in terms of 8 bit bytes
and characters for the second approach to be preferred. Trying to
handle Telnet or HTTP with 1 CHARS = 2 would be seriously unpleasant.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#35974

In article <54c22cf9.515098437@news.eternal-september.org>,
Stephen Pelc <stephen@mpeforth.com> wrote:
>On Thu, 22 Jan 2015 11:13:18 -0800, Paul Rubin
><no.email@nospam.invalid> wrote:
>
>>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> at least 1 CHARS = 1 (so CHARS and friends can go)....
>>
>>That sounds like a declaration of ignoring Unicode.  From a Forth
>>perspective, maybe that's a good thing, but it seems a bit
>>anachronistic.
>
>No, no, no. In Forth-200x terminology, what used to be called
>a character is now called a primitive character, or pchar for
>short. UTF-8 is built from one or more pchars and UTF-16 can be
>handled by 1 CHARS = 2 (the trad solution) or by 1 CHARS = 1 and
>use of the wide character extensions.
>
>There are enough comms protocols defined in terms of 8 bit bytes
>and characters for the second approach to be preferred. Trying to
>handle Telnet or HTTP with 1 CHARS = 2 would be seriously unpleasant.

And then there are address units.

>
>Stephen
-- 
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]

#35976

Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> at least 1 CHARS = 1 (so CHARS and friends can go).... 
>
>That sounds like a declaration of ignoring Unicode.

No, you can have Unicode with 8-bit chars in the form of UTF-8 (see
the Forth-2012 xchar wordset if you want to deal with individual
Unicode code points in such a setting).  Or you can have, say, UTF-32
and 32-bit or 64-bit address units.  But most systems use 8-bit chars.

>From a Forth
>perspective, maybe that's a good thing, but it seems a bit
>anachronistic.

It's your view that Unicode requires wide chars that's anachronistic.
UTF-8 was invented over 20 years ago.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#35990

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> No, you can have Unicode with 8-bit chars in the form of UTF-8 

I'm used to the term "character" in unicode parlance as meaning a code
point.  UTF-8 is a way to encode a character as one or more bytes.

> But most systems use 8-bit chars.

In a world that recognizes unicode, it's probably best to refer to that
8-bit unit as a byte or an octet.

[toc] | [prev] | [next] | [standalone]

#35993

Paul Rubin wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> No, you can have Unicode with 8-bit chars in the form of UTF-8
> 
> I'm used to the term "character" in unicode parlance as meaning a code
> point.  UTF-8 is a way to encode a character as one or more bytes.

In Forth2012 speek, that's an extended character (i.e. a multi-byte 
character).

>> But most systems use 8-bit chars.
> 
> In a world that recognizes unicode, it's probably best to refer to that
> 8-bit unit as a byte or an octet.

It mostly is.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web