Can you turn off Pipeline in ARM Cortex M3

On 11/09/15 09:52, rickman wrote:
> On 9/11/2015 3:37 AM, George Neuner wrote:
>> On Fri, 11 Sep 2015 00:04:18 -0400, rickman <gnuarm@gmail.com> wrote:
>>
>>> I don't see any difference in behavior between the two ALT keys.
>>
>> There is no difference unless software defines it.
> 
> What software is doing this?  Are the BIOS in PCs sold outside the US
> different?  I thought it was windows that set the char set.  I had no
> idea it would also give the ALT keys different functions.

The keyboard scan codes are built into the keyboard - they are reported
on USB, PS/2, Bluetooth, or whatever other interface is used.  Then it
is up to the software controlling it to interpret the scan codes in the
way it wants.

Simple software, such as the BIOS, only does simple handling - typically
not supporting different keyboard layouts.

DOS and Windows support a variety of layouts, which is chosen by
configuration of the OS - it is completely independent of the BIOS, and
of whatever keys happen to be on the keyboard.  The US keyboard layout
on Windows is pretty simplistic - amongst other things it makes little
distinction between the left and right Alt keys (though only the right
one works with the numeric keypad for entering ASCII/utf codes), and it
has no support for dead keys.

Many international keyboard layouts are a bit more sophisticated, with a
separation between Alt and AltGr (right-hand Alt) which lets you use the
normal Alt for menu shortcuts, etc., and the right-hand AltGr to get
more symbols, accents or letters required for other languages.  They
also generally support dead keys.

A dead key is one that does not generate any character when pressed,
until you press another key.  For example, in many layouts the backtick
` is a dead key.  Pressing it does not produce anything unless you
follow it with a space or a new ` to get a ` symbol.  But if you follow
it with an e, you get &#4294967295;.  Similarly, &#4294967295; is produced by pressing &#4294967295; and then u.

More advanced software, such as X, support much more configurable
keyboard setups, and many more accessible characters.

> 
> 
>> Each key on the keyboard has a unique "scan" code, which differs from
>> the "character" code.  [This is how keyboard remappers work.]
>> Using the scan codes, left and right ALT and CTRL keys can be
>> distinguished, but the default keyboard handler simply returns the
>> same character code for both keys.  You need to do a raw read of the
>> keyboard device to see the different scan codes.
>>
>> Most software works just with character codes and doesn't need to know
>> which keys actually were pressed.
>>
>>
>>> Both work fine with the key codes I provided and neither work as the
>>> AltGr key is described.
>>
>> https://en.wikipedia.org/wiki/AltGr_key
>>
>> The "AltGr" key on non-US keyboards has the same scan code as the
>> right ALT key on US keyboards, so it is the software that makes it
>> operate differently.
>>
>> George
>>
> 
> 

Den fredag den 11. september 2015 kl. 06.04.23 UTC+2 skrev rickman:
> On 9/10/2015 11:31 PM, George Neuner wrote:
> > On Thu, 10 Sep 2015 23:17:28 -0400, George Neuner
> > <gneuner2@comcast.net> wrote:
> >
> >> Some compatibles allowed to use either ALT key, but IBM PCs did not
> >> and so the right hand ALT key was "special".
> >
> > Just to be clear - this was an issue of PC-DOS vs MS-DOS.  IBM only
> > used the right ALT key, compatibles did whatever they wanted.
> >
> > Any program could hook into the keyboard read/filter chain to see the
> > actual key presses ... the limitation of only using the right hand ALT
> > key to enter alternate characters was just the default behavior under
> > PC-DOS.
> 
> I don't see any difference in behavior between the two ALT keys.  Both 
> work fine with the key codes I provided and neither work as the AltGr 
> key is described.  It is much handier to use the left ALT key while 
> entering digits with the right hand.
> 

here's a danish keyboard, all the blue  symbols are made with ALT-GR

https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/KB_Danish.svg/2000px-KB_Danish.svg.png

the left ALT doesn't do the same

i believe all most all the keys have separate scan code, so if you wanted to 
you could make left and right shift or ctrl key do something different

-Lasse

Am 11.09.2015 um 06:04 schrieb rickman:

> I don't see any difference in behavior between the two ALT keys.

Then you're using the plain US-american keyboard layout.  This is  great 
for programming because all of []{}()<> and \| are easy to reach.

It's not so great for entering text in languages other than English 
which use lots of d&#4294967295;&#4294967295;cr&#4294967295;t&#4294967295;cs, or characters outside the standard 
alphabets like German &#4294967295;&#4294967295;&#4294967295;&#4294967295;, though.  Even typing currency symbols other 
than the $ is hard on the default US keymap.  So what about &#4294967295;, or &#4294967295;?

All this is the reason PC's have had localized keyboard layouts since 
just about forever.  Many of these have one or two more keys than the 
US' 101.  But that's not sufficient to accomodate all those accents and 
special characters. So at some point, the non-English special keys will 
squeeze some (presumably) not-so-frequently used keys off the layout. 
Typical victims of this include []{}<>\|~# and @.

> Bothwork fine with the key codes I provided and neither work as the AltGr
> key is described.

International layouts have to routinely sacrifice the right Alt keys' 
original function to provide a secondary "shift" function that gives 
back access to those characters which got squeezed off the original 
layout.  E.g. on the German layout, to get \ one can either type 
Ctrl+leftAlt+&#4294967295;, or rightAlt + &#4294967295;.  To indicate this difference, the right 
Alt is relabeled AltGr (for "alternative graphic characters" or 
something like that).  One consequence is that the Alt+<numeric keypad> 
only work with the left Alt key on these layout.

Incidentally, this makes typing C source on non-US PC keyboards a royal 
pain, particularly if you've mastered touch typing.  IMHO it qualifies 
as a miracle that any working C code was ever written in Belgium or 
Switzerland :-)

On Sat, 12 Sep 2015 01:05:55 +0200, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>International layouts have to routinely sacrifice the right Alt keys' 
>original function to provide a secondary "shift" function that gives 
>back access to those characters which got squeezed off the original 
>layout.  
>    :
>Incidentally, this makes typing C source on non-US PC keyboards a royal 
>pain, particularly if you've mastered touch typing.  IMHO it qualifies 
>as a miracle that any working C code was ever written in Belgium or 
>Switzerland :-)

I wonder now if the keyboard was part of the reason that Pascal family
languages remained popular in Europe much longer than they did in the
US.

George

George Neuner wrote:
> On Sat, 12 Sep 2015 01:05:55 +0200, Hans-Bernhard Br�ker
> <HBBroeker@t-online.de> wrote:
>
>> International layouts have to routinely sacrifice the right Alt keys'
>> original function to provide a secondary "shift" function that gives
>> back access to those characters which got squeezed off the original
>> layout.
>>     :
>> Incidentally, this makes typing C source on non-US PC keyboards a royal
>> pain, particularly if you've mastered touch typing.  IMHO it qualifies
>> as a miracle that any working C code was ever written in Belgium or
>> Switzerland :-)
>
> I wonder now if the keyboard was part of the reason that Pascal family
> languages remained popular in Europe much longer than they did in the
> US.
>
> George
>

I was around when Pascal got supplanted by 'C' in the U.S. I think
Borland sank Pascal when they went to a 'C' offering. But
they were chasing Microsoft.

We have to be careful, because there's always
observer bias. But 'C' had semi-legendary status back
to when I was in school in the early '80s
without the ability to use 'C'.

The tribe I was with went first to MSC then to Borland, a
lot because of Paradigm Locate and how well it worked
with Borland tools to produce ROMable images.

Side note: I got handed a Netburner a year or two  ago,
which still uses the Borland tool chain. I maxed out the
available memory  on the second day* and gave up :)  The
symptom was a complete latchup of the target. The weary
support person had the solution far too ready.

*application already ran on a big ARM platform.

The  old days weren't so good :)

-- 
Les Cargill

On 12/09/15 01:05, Hans-Bernhard Br�ker wrote:

> Incidentally, this makes typing C source on non-US PC keyboards a royal
> pain, particularly if you've mastered touch typing.  IMHO it qualifies
> as a miracle that any working C code was ever written in Belgium or
> Switzerland :-)

You get used to it quickly - I found it a slight inconvenience for a few 
weeks when I moved to Norway, but not more than that.  It was actually 
not the {[]} symbols, that need the AltGr key on a Norwegian layout, 
that were the most annoying.  It is the shifted symbols above the number 
keys that are worst (at least when I now occasionally have to deal with 
a US or UK layout).

And there is the odd program around whose developers think the world 
ends at the borders of the USA, and can't cope when the keyboard layout 
is different.  But fortunately those are rare.

On 12/09/15 03:20, George Neuner wrote:
> On Sat, 12 Sep 2015 01:05:55 +0200, Hans-Bernhard Br�ker
> <HBBroeker@t-online.de> wrote:
>
>> International layouts have to routinely sacrifice the right Alt keys'
>> original function to provide a secondary "shift" function that gives
>> back access to those characters which got squeezed off the original
>> layout.
>>     :
>> Incidentally, this makes typing C source on non-US PC keyboards a royal
>> pain, particularly if you've mastered touch typing.  IMHO it qualifies
>> as a miracle that any working C code was ever written in Belgium or
>> Switzerland :-)
>
> I wonder now if the keyboard was part of the reason that Pascal family
> languages remained popular in Europe much longer than they did in the
> US.
>

No, that would have absolutely nothing to do with it.  It is not hard to 
type {} on non-US keyboards - it is certainly quicker and shorter than 
typing begin/end.  And despite the myth that many design decisions in C 
were because of the terrible DEC keyboards used by K&R, such 
considerations are totally insignificant in choosing a language. 
(Except for APL, of course.)

On Fri, 11 Sep 2015 22:03:35 -0500, Les Cargill
<lcargill99@comcast.com> wrote:

>George Neuner wrote:
>
>> I wonder now if the keyboard was part of the reason that Pascal family
>> languages remained popular in Europe much longer than they did in the
>> US.
>
>I was around when Pascal got supplanted by 'C' in the U.S. 

Same here.

But languages evolve and I have always wondered why some of the more
capable family members didn't generate more interest.

Apple pushed Object Pascal quite hard with Lisa and Mac.  It was a
number of years before they made C available [as an Apple product -
there were Macintosh C compilers available from other vendors.  I
don't ever recall seeing C for the Lisa].

I really liked Modula 3.  I know Wirth himself had nothing to do with
it, but it was based on (extended) Modula 2 and I consider it to be in
the Pascal family [a cousin maybe].


>Borland sank Pascal when they went to a 'C' offering. But they
>were chasing Microsoft.

I'm not sure I really agree with that.  They continued to work on and
improve Pascal long after they introduced the C compiler.

I think the problem far more was delay in offering a decent Pascal for
Windows ... TPW on Windows 3 was horrible.  It took them 6 years to
bring out Delphi and although it could [theoretically] run on Windows
3 or 95, it was unstable on those systems and really needed NT4 to do
serious work.  For quite a while there was no low-cost starter
version, so until Win98 came along, Delphi effectively excluded many
students and hobbyists.

I don't recall other Pascals being available for Windows early on, so
Borland's mis-steps there certainly can be credited with Pascal's
demise.  I just don't think their offering C had quite so much to do
with it.  YMMV.

George

On Sat, 12 Sep 2015 14:36:46 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 12/09/15 03:20, George Neuner wrote:
>
>> I wonder now if the keyboard was part of the reason that Pascal family
>> languages remained popular in Europe much longer than they did in the
>> US.
>
>No, that would have absolutely nothing to do with it.  It is not hard to 
>type {} on non-US keyboards - it is certainly quicker and shorter than 
>typing begin/end.  And despite the myth that many design decisions in C 
>were because of the terrible DEC keyboards used by K&R, such 
>considerations are totally insignificant in choosing a language. 
>(Except for APL, of course.)

Source code is intended to be read by humans as well as by compilers. 
I use C because employers will pay me to do so, not because I
particularly like it.  All of C's power [and then some] is available
in languages that are safer to use and don't look so much like line
noise.  That may not have been true in 1975  [though I could make a
case that it was], but it certainly was true by 1985.  

George

George Neuner wrote:
> On Fri, 11 Sep 2015 22:03:35 -0500, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> George Neuner wrote:
>>
>>> I wonder now if the keyboard was part of the reason that Pascal family
>>> languages remained popular in Europe much longer than they did in the
>>> US.
>>
>> I was around when Pascal got supplanted by 'C' in the U.S.
>
> Same here.
>
> But languages evolve and I have always wondered why some of the more
> capable family members didn't generate more interest.
>

Beats me. But I don't consider Pascal that vast an improvement
over 'C'. No disrespect to Wirth, but I disagree
with his complaints about that.

> Apple pushed Object Pascal quite hard with Lisa and Mac.  It was a
> number of years before they made C available [as an Apple product -
> there were Macintosh C compilers available from other vendors.  I
> don't ever recall seeing C for the Lisa].
>
> I really liked Modula 3.  I know Wirth himself had nothing to do with
> it, but it was based on (extended) Modula 2 and I consider it to be in
> the Pascal family [a cousin maybe].
>
>

Agreed - but I never saw any interest in it. There was a short span
of time where I could be on a project that mixed 68000 and x86,
and the most sensible thing seemed to be 'C' for that.

>> Borland sank Pascal when they went to a 'C' offering. But they
>> were chasing Microsoft.
>
> I'm not sure I really agree with that.  They continued to work on and
> improve Pascal long after they introduced the C compiler.
>
> I think the problem far more was delay in offering a decent Pascal for
> Windows ... TPW on Windows 3 was horrible.  It took them 6 years to
> bring out Delphi and although it could [theoretically] run on Windows
> 3 or 95, it was unstable on those systems and really needed NT4 to do
> serious work.  For quite a while there was no low-cost starter
> version, so until Win98 came along, Delphi effectively excluded many
> students and hobbyists.
>

Excellent point - I sort of recall that now. I had
one contact who used Delphi and he'd complained about this.

It never made sense to me that it should be unstable.

> I don't recall other Pascals being available for Windows early on, so
> Borland's mis-steps there certainly can be credited with Pascal's
> demise.  I just don't think their offering C had quite so much to do
> with it.  YMMV.
>

It's probably observer bias on my part - the people I knew who could
decide between Pascal and 'C' weren't writing GUI applications and
'C' was the better choice for systems work.

> George
>

-- 
Les Cargill