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

Groups > comp.arch.embedded > #30821 > unrolled thread

How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on

Back to article view | Back to comp.arch.embedded

Contents

  How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-23 00:07 +0200
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Clifford Heath <no.spam@please.net> - 2021-10-23 13:40 +1100
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-22 22:09 -0700
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-23 22:12 +0200
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-23 15:59 -0700
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-23 18:09 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-23 22:49 +0200
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-24 13:02 +0200
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-24 17:39 +0200
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-24 18:37 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-25 20:15 +0200
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 20:54 +0200
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Richard Damon <Richard@Damon-Family.org> - 2021-10-25 20:31 -0400
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Johann Klammer <klammerj@NOSPAM.a1.net> - 2021-10-24 12:39 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-24 14:14 +0300
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 12:54 -0700
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-24 23:27 +0300
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 14:08 -0700
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 00:50 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 15:47 -0700
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 02:32 +0300
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 18:34 -0700
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 09:41 +0200
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 10:56 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 01:19 -0700
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 11:52 +0300
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 02:50 -0700
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 13:49 +0200
                      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 15:16 +0300
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 11:09 +0300
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 01:28 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 12:06 +0300
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 02:35 -0700
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 16:04 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 18:34 +0300
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 10:43 -0700
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 20:53 +0300
                      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 11:02 -0700
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-25 19:52 +0200
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 11:10 -0700
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 21:33 +0300
                      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 22:09 +0300
                        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 22:53 +0300
                          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 23:02 +0300
                            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-26 00:05 +0200
                      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-25 23:46 +0200
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 20:58 +0200
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Clifford Heath <no.spam@please.net> - 2021-10-26 08:43 +1100
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-25 21:32 +0000
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 15:24 -0700
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-27 00:20 +0000
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-26 17:52 -0700
                  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-27 05:22 +0000
                    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-29 15:36 -0700
                      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-31 22:54 +0000
                        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-31 20:37 -0700
                          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-11-11 04:34 +0000
                            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-11-19 16:21 -0700
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 08:57 +0200

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

#30838

On 10/25/2021 1:47, Don Y wrote:
> ...
> 
> ASM has always been available. 

There is no such language as ASM, there is a wide variety of machines.

> Folks just found it too inefficient
> to solve "big" problems, in reasonable effort.

Especially with the advent of load/store machines (although C must have
been helped a lot by the clunky x86 architecture for its popularity),
programming in the native assembler for any RISC machine would be
masochistic at best. Which is why I took the steps I took etc., no
need to go into that.

> 
>> I am not denying this is the best
>> language currently available to almost everybody. I just happened to
>> have been daring enough to explore my own way/language and have seen
>> how much is there to be gained if not having to wrestle a language
>> which is just a more complete phrase book than the rest of the
>> phrase books (aka high level languages).
> 
> But you only have yourself as a client. 

Yes, but this does not mean much. Looking at pieces I wrote 20 or
30 years ago - even 10 years ago sometimes - is like reading it
for the first time for many parts (tens of megabytes of sources,
http://tgi-sci.com/misc/scnt21.gif ).

> Most of us have to write code
> (or modify already written code) that others will see/maintain.  It
> does no good to have a "great tool" if no one else uses it! >
> I use (scant!) ASM, a modified ("proprietary") C dialect, SQL and a 
> scripting
> language in my current design.  (not counting the tools that generate my
> documentation).

Here comes the advantage of an "alphabet" rather than "hieroglyph" based
approach/language. A lot less of lookup tables to memorize, you learn
while going etc. I am quite sure someone like you would get used to it
quite fast, much much faster than to an unknown high level language.
In fact it may take you very short to see it is something you have more
or less been familiar with forever.
Grasping the big picture of the entire environment and becoming
really good at writing within it would take longer, obviously.

> ....
>>>
>>> Hear much latin or ancient greek spoken, recently?
>>
>> The Latin alphabet looks pretty popular nowadays :-). Everything
>> evolves, including languages. And there are dead ends within them
>> which just die out - e.g. roman numbers. Can't see much future in
>> any hieroglyph based language though, inventing a symbol for each
>> word has been demonstrated to be a bad idea by history.
> 
> Witness the rise of arabic numerals and their efficacy towards
> advancing mathematics.

Yes, another good example of how it is the foundation you step on
that really matters. Step on the Roman numbers and good luck with
your math...

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

#30839

On 10/24/2021 4:32 PM, Dimiter_Popoff wrote:
> On 10/25/2021 1:47, Don Y wrote:
>> ...
>>
>> ASM has always been available. 
> 
> There is no such language as ASM, there is a wide variety of machines.

Of course there's a language called ASM!  It's just target specific!
It is available for each different processor.

And highly NONportable!

>> Folks just found it too inefficient
>> to solve "big" problems, in reasonable effort.
> 
> Especially with the advent of load/store machines (although C must have
> been helped a lot by the clunky x86 architecture for its popularity),
> programming in the native assembler for any RISC machine would be
> masochistic at best. Which is why I took the steps I took etc., no
> need to go into that.
> 
>>> I am not denying this is the best
>>> language currently available to almost everybody. I just happened to
>>> have been daring enough to explore my own way/language and have seen
>>> how much is there to be gained if not having to wrestle a language
>>> which is just a more complete phrase book than the rest of the
>>> phrase books (aka high level languages).
>>
>> But you only have yourself as a client. 
> 
> Yes, but this does not mean much. Looking at pieces I wrote 20 or
> 30 years ago - even 10 years ago sometimes - is like reading it
> for the first time for many parts (tens of megabytes of sources,
> http://tgi-sci.com/misc/scnt21.gif ).

Of course it means something!  If someone else has to step into
your role *tomorrow*, there'd be little/no progress on your codebase
until they learned your toolchain/language.

An employer has to expect that any employee can "become unavailable"
at any time.  And, with that, the labors for which they'd previously
paid, should still retain their value.  I've had clients outright ask
me, "What happens if you get hit by a bus?"

>> Most of us have to write code
>> (or modify already written code) that others will see/maintain.  It
>> does no good to have a "great tool" if no one else uses it! >
>> I use (scant!) ASM, a modified ("proprietary") C dialect, SQL and a scripting
>> language in my current design.  (not counting the tools that generate my
>> documentation).
> 
> Here comes the advantage of an "alphabet" rather than "hieroglyph" based
> approach/language. A lot less of lookup tables to memorize, you learn
> while going etc. I am quite sure someone like you would get used to it
> quite fast, much much faster than to an unknown high level language.
> In fact it may take you very short to see it is something you have more
> or less been familiar with forever.
> Grasping the big picture of the entire environment and becoming
> really good at writing within it would take longer, obviously.

But that can be said of any HLL.  That doesn't mean an employer
wants to pay you to *learn* (some *previous* employer was expected
to have done that!).  They want to have to, at most, train you on
the needs of their applications/markets.

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

#30841

On 24/10/2021 23:08, Don Y wrote:

> The language isn't the problem.  Witness the *millions* (?) of programs
> written in it, over the past 5 decades.
> 
> The problem is that it never was an assembly language -- even though it
> was treated as such "in days gone by" (because the compiler's were
> just "language translators" and didn't add any OTHER value to the
> "programming process").
> 

No - the problem is that some people /thought/ it was supposed to be a
kind of assembly language.  It's a people problem, not a language
problem.  C has all you need to handle code such as the OP's - all it
takes is for people to understand that they need to use the right
features of the language.

> It's only recently that compilers have become "independent agents",
> of a sort... adding their own "spin" on the developer's code.
> 

Baring bugs, compilers do what they are told - in the language
specified.  If programmers don't properly understand the language they
are using, or think it means more than it does, that's the programmers
that are at fault - not the language or the compiler.  If you go into a
French bakery and ask for horse dung instead of the end of a baguette,
that's /your/ fault - not the language's fault, and not the baker's fault.

Add to that, the idea that optimising compilers are new is equally silly.

The C language is defined in terms of an "abstract machine".  The
generated code has the same effect "as if" it executed everything you
wrote - but the abstract machine and the real object code only
synchronise on the observable behaviour.  In practice, that means
volatile accesses happen exactly as often, with exactly the values and
exactly the order that you gave in the code.  Non-volatile accesses can
be re-ordered, re-arranged, combined, duplicated, or whatever.

This has been the situation since C was standardised and since more
advanced compilers arrived, perhaps 30 years ago.


C is what it is - a language designed long ago, but which turned out to
be surprisingly effective and long-lived.  It's not perfect, but it is
pretty good and works well for many situations where you need low-level
coding or near-optimal efficiency.  It's not as safe or advanced as many
new languages, and it is not a beginners' language - you have to know
what you are doing in order to write C code correctly.  You have to
understand it and follow its rules, whether you like these rules or not.

Unfortunately, there are quite a few C programmers who /don't/ know
these rules.  And there is a small but vocal fraction who /do/ know the
rules, but don't like them and feel the rules should therefore not apply
- and blame compilers, standards committees, and anyone else when things
inevitably go wrong.  Some people are always a problem, regardless of
the language!

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

#30842

On 2021-10-25 0:08, Don Y wrote:

    [snip]


> There are (and have been) many "safer" languages.  Many that are more
> descriptive (for certain classes of problem).  But, C has survived to
> handle all-of-the-above... perhaps in a suboptimal way but at least
> a manner that can get to the desired solution.
> 
> Look at how few applications SNOBOL handles.  Write an OS in COBOL?  Ada?


I don't know about COBOL, but typically the real-time kernels ("run-time 
systems") associated with Ada compilers for bare-board embedded systems 
are written in Ada, with a minor amount of assembly language for the 
most HW-related bits like HW context saving and restoring. I'm pretty 
sure that C-language OS kernels also use assembly for those things.

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

#30844

On 10/25/2021 12:56 AM, Niklas Holsti wrote:
> On 2021-10-25 0:08, Don Y wrote:
> 
>> There are (and have been) many "safer" languages.  Many that are more
>> descriptive (for certain classes of problem).  But, C has survived to
>> handle all-of-the-above... perhaps in a suboptimal way but at least
>> a manner that can get to the desired solution.
>>
>> Look at how few applications SNOBOL handles.  Write an OS in COBOL?  Ada?
> 
> I don't know about COBOL, but typically the real-time kernels ("run-time 
> systems") associated with Ada compilers for bare-board embedded systems are 
> written in Ada, with a minor amount of assembly language for the most 
> HW-related bits like HW context saving and restoring. I'm pretty sure that 
> C-language OS kernels also use assembly for those things.

Of course you *can* do these things.  The question is how often
they are ACTUALLY done with these other languages.

"Suitability for a particular task" isn't often the criteria that is
used to make a selection -- for better or worse.  There are countless
other factors that affect an implementation, depending on the environment
in which it is undertaken (e.g., designs from academia are considerably
different than hobbyist designs which are different from commercial
designs which are...)

This is true of other disciplines, as well.  How often do you think a hardware
design follows a course heavily influenced by the "prejudices"/"preferences"
of the folks responsible for the design vs. the "best" approach to it?

Step back yet another level of abstraction and see that even the tools
chosen to perform those tasks are often not "optimally chosen".

If you are the sole entity involved in a decision making process, then
you've (typically) got /carte blanche/.  But, in most cases, there are
other voices -- seats at the table -- that shape the final decisions.  It
pays to lift one's head and see which way the wind is blowing, *today*...

[By the same token, expecting the past to mirror the present is equally
naive.  People forget that tools and processes have evolved (in the 40+
years that I've been designing embedded products).  And, that the isssues
folks now face often weren't issues when tools were "stupider" (I've
probably got $60K of obsolete compilers to prove this -- anyone written
any C on an 1802 recently?  Or, a 2A03?  65816?  Z180?  6809?)  Don't
even *think* about finding an Ada compiler for them -- in the past!]

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

#30846

On 2021-10-25 11:19, Don Y wrote:
> On 10/25/2021 12:56 AM, Niklas Holsti wrote:
>> On 2021-10-25 0:08, Don Y wrote:
>>
>>> There are (and have been) many "safer" languages.  Many that are more
>>> descriptive (for certain classes of problem).  But, C has survived to
>>> handle all-of-the-above... perhaps in a suboptimal way but at least
>>> a manner that can get to the desired solution.
>>>
>>> Look at how few applications SNOBOL handles.  Write an OS in COBOL?  
>>> Ada?
>>
>> I don't know about COBOL, but typically the real-time kernels 
>> ("run-time systems") associated with Ada compilers for bare-board 
>> embedded systems are written in Ada, with a minor amount of assembly 
>> language for the most HW-related bits like HW context saving and 
>> restoring. I'm pretty sure that C-language OS kernels also use 
>> assembly for those things.
> 
> Of course you *can* do these things.


Then I misunderstood your (rhetorical?) question.


> The question is how often
> they are ACTUALLY done with these other languages.


I don't find that question very interesting.

It is a typical chicken-and-egg, first-to-market conundrum. There is an 
enormous amount of status-quo-favouring friction in awareness, 
education, tool availability, and legacy code.


> [By the same token, expecting the past to mirror the present is equally
> naive.  People forget that tools and processes have evolved (in the 40+
> years that I've been designing embedded products).  And, that the isssues
> folks now face often weren't issues when tools were "stupider" (I've
> probably got $60K of obsolete compilers to prove this -- anyone written
> any C on an 1802 recently?  Or, a 2A03?  65816?  Z180?  6809?)  Don't
> even *think* about finding an Ada compiler for them -- in the past!]


Well, the Janus/Ada compiler was available for Z80 in its day. There are 
also Ada compilers that use C as an intermediate language, with 
applications for example on TI MSP430's, but those were probably not 
available in the past ages you refer to.

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

#30849

On 10/25/2021 1:52 AM, Niklas Holsti wrote:
> On 2021-10-25 11:19, Don Y wrote:
>> On 10/25/2021 12:56 AM, Niklas Holsti wrote:
>>> On 2021-10-25 0:08, Don Y wrote:
>>>
>>>> There are (and have been) many "safer" languages.  Many that are more
>>>> descriptive (for certain classes of problem).  But, C has survived to
>>>> handle all-of-the-above... perhaps in a suboptimal way but at least
>>>> a manner that can get to the desired solution.
>>>>
>>>> Look at how few applications SNOBOL handles.  Write an OS in COBOL? Ada?
>>>
>>> I don't know about COBOL, but typically the real-time kernels ("run-time 
>>> systems") associated with Ada compilers for bare-board embedded systems are 
>>> written in Ada, with a minor amount of assembly language for the most 
>>> HW-related bits like HW context saving and restoring. I'm pretty sure that 
>>> C-language OS kernels also use assembly for those things.
>>
>> Of course you *can* do these things.
> 
> Then I misunderstood your (rhetorical?) question.
> 
>> The question is how often
>> they are ACTUALLY done with these other languages.
> 
> I don't find that question very interesting.

Why not?  If a tool isn't used for a purpose for which it *should*
be "ideal", you have to start wondering "why not?"  Was it NOT
suited to the task?  Was it too costly (money and/or experience)?
How do we not repeat that problem, going forward?  I.e., is it
better to EVOLVE a language to acquire the characteristics of the
"better" one -- rather than trying to encourage people to
"jump ship"?

> It is a typical chicken-and-egg, first-to-market conundrum. There is an 
> enormous amount of status-quo-favouring friction in awareness, education, tool 
> availability, and legacy code.

Of course!

And, there is also the pressure of the market.  Do *you* want to be The Guy
who tries something new and sinks a product's development or market release?
If your approach proves to be a big hit, will you benefit as much as you'd
LOSE if it was a flop?

>> [By the same token, expecting the past to mirror the present is equally
>> naive.  People forget that tools and processes have evolved (in the 40+
>> years that I've been designing embedded products).  And, that the isssues
>> folks now face often weren't issues when tools were "stupider" (I've
>> probably got $60K of obsolete compilers to prove this -- anyone written
>> any C on an 1802 recently?  Or, a 2A03?  65816?  Z180?  6809?)  Don't
>> even *think* about finding an Ada compiler for them -- in the past!]
> 
> Well, the Janus/Ada compiler was available for Z80 in its day. There are also 
> Ada compilers that use C as an intermediate language, with applications for 
> example on TI MSP430's, but those were probably not available in the past ages 
> you refer to.

I recall JRT Pascal and PL/M as the "high level" languages, back then.
C compilers were notoriously bad.  You could literally predict the
code that would be generated for any statement.  The whole idea of
"peephole optimizers" looking for:
     STORE A
     LOAD A
sequences to elide is testament to how little global knowledge they
had of the code they were processing.

Performance?  A skilled ASM coder could beat the generated code
(in time AND space) without breaking into a sweat.

And, you bought a compiler/assembler/linker/debugger for *each*
processor -- not just a simple command line switch to alter the
code generation, etc.  Vendors might have a common codebase
for the tools but built each variant conditionally.

The limits of the language were largely influenced by the targeted
hardware -- "helper routines" to support longs, floats, etc.
("Oh, did you want that support to be *reentrant*?  We assumed
there would be a single floating point accumulator used throughout
the code, not one per thread!")  Different sizes of addresses
(e.g., for the Z180, you could have 16b "logical" addresses
and 24b physical addresses -- mapped into that logical space
by the compiler's runtime support and linkage editor.)

Portable code?  Maybe -- with quite a bit of work!

Fast/small?  Meh...

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

#30851

On 25/10/2021 10:52, Niklas Holsti wrote:

> 
> Well, the Janus/Ada compiler was available for Z80 in its day. There are
> also Ada compilers that use C as an intermediate language, with
> applications for example on TI MSP430's, but those were probably not
> available in the past ages you refer to.

Presumably there is gcc-based Ada for the msp430 (as there is for the
8-bit AVR)?  There might not be a full library available, or possibly
some missing features in the language.

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

#30852

On 2021-10-25 14:49, David Brown wrote:
> On 25/10/2021 10:52, Niklas Holsti wrote:
> 
>>
>> Well, the Janus/Ada compiler was available for Z80 in its day. There are
>> also Ada compilers that use C as an intermediate language, with
>> applications for example on TI MSP430's, but those were probably not
>> available in the past ages you refer to.
> 
> Presumably there is gcc-based Ada for the msp430 (as there is for the
> 8-bit AVR)?


Indeed there seems to be one, or at least work towards one: 
https://sourceforge.net/p/msp430ada/wiki/Home/.


> There might not be a full library available, or possibly
> some missing features in the language.


Certainly. I think that Janus/Ada for the Z80 was limited to the 
original Ada (Ada 83), and may well have also had some significant 
missing features. But I believe it was self-hosted on CP/M, quite a feat.

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

#30843

On 2021-10-24 23:27, Dimiter_Popoff wrote:
> On 10/24/2021 22:54, Don Y wrote:
>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>> Disable interrupts while accessing the fifo. you really have to.
>>>> alternatively you'll often get away not using a fifo at all,
>>>> unless you're blocking for a long while in some part of the code.
>>>
>>> Why would you do that. The fifo write pointer is only modified by
>>> the interrupt handler, the read pointer is only modified by the
>>> interrupted code. Has been done so for times immemorial.
>>
>> The OPs code doesn't differentiate between FIFO full and empty.
> 
> So he should fix that first, there is no sane reason why not.
> Few things are simpler to do than that.


    [snip]


> Whatever handshakes he makes there is no problem knowing whether
> the fifo is full - just check if the position the write pointer
> will have after putting the next byte matches the read pointer
> at the moment.  Like I said before, few things are simpler than
> that, can't imagine someone working as a programmer being
> stuck at *that*.

That simple check would require keeping a maximum of only N-1 entries in 
the N-position FIFO buffer, and the OP explicitly said they did not want 
to allocate an unused place in the buffer (which I think is unreasonable 
of the OP, but that is only IMO).

The simple explanation for the N-1 limit is that the difference between 
two wrap-around pointers into an N-place buffer has at most N different 
values, while there are N+1 possible filling states of the buffer, from 
empty (zero items) to full (N items).

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

#30845

On 10/25/2021 1:09 AM, Niklas Holsti wrote:
> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>> On 10/24/2021 22:54, Don Y wrote:
>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>> alternatively you'll often get away not using a fifo at all,
>>>>> unless you're blocking for a long while in some part of the code.
>>>>
>>>> Why would you do that. The fifo write pointer is only modified by
>>>> the interrupt handler, the read pointer is only modified by the
>>>> interrupted code. Has been done so for times immemorial.
>>>
>>> The OPs code doesn't differentiate between FIFO full and empty.
>>
>> So he should fix that first, there is no sane reason why not.
>> Few things are simpler to do than that.
> 
> 
>     [snip]
> 
> 
>> Whatever handshakes he makes there is no problem knowing whether
>> the fifo is full - just check if the position the write pointer
>> will have after putting the next byte matches the read pointer
>> at the moment.  Like I said before, few things are simpler than
>> that, can't imagine someone working as a programmer being
>> stuck at *that*.
> 
> That simple check would require keeping a maximum of only N-1 entries in the 
> N-position FIFO buffer, and the OP explicitly said they did not want to 
> allocate an unused place in the buffer (which I think is unreasonable of the 
> OP, but that is only IMO).
> 
> The simple explanation for the N-1 limit is that the difference between two 
> wrap-around pointers into an N-place buffer has at most N different values, 
> while there are N+1 possible filling states of the buffer, from empty (zero 
> items) to full (N items).

But, again, that just deals with the "full check".  The easiest way to do
this is just to check ".in" *after* advancement and inhibit the store if
it coincides with the ".out" value.

Checking for a "high water mark" to enable flow control requires more
computation (albeit simple) as you have to accommodate the delays in
that notification reaching the remote sender (lest he continue
sending and overrun your buffer).

And, later noting when you've consumed enough of the FIFO's contents
to reach a "low water mark" and reenable the remote's transmissions.

[And, if you ever have to deal with more "established" protocols
that require the sequencing of specific control signals DURING
a transfer, the ISR quickly becomes very complex!]

When you start "fleshing out" an ISR in this way, you see the code
quickly becomes more involved than just pushing bytes into a buffer.
(and, this should give you pause to rethink what you are doing *in*
the ISR and what can best be handled out of that "precious"
environment)

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

#30847

On 2021-10-25 11:28, Don Y wrote:
> On 10/25/2021 1:09 AM, Niklas Holsti wrote:
>> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>>> On 10/24/2021 22:54, Don Y wrote:
>>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>>> alternatively you'll often get away not using a fifo at all,
>>>>>> unless you're blocking for a long while in some part of the code.
>>>>>
>>>>> Why would you do that. The fifo write pointer is only modified by
>>>>> the interrupt handler, the read pointer is only modified by the
>>>>> interrupted code. Has been done so for times immemorial.
>>>>
>>>> The OPs code doesn't differentiate between FIFO full and empty.
>>>
>>> So he should fix that first, there is no sane reason why not.
>>> Few things are simpler to do than that.
>>
>>
>>     [snip]
>>
>>
>>> Whatever handshakes he makes there is no problem knowing whether
>>> the fifo is full - just check if the position the write pointer
>>> will have after putting the next byte matches the read pointer
>>> at the moment.  Like I said before, few things are simpler than
>>> that, can't imagine someone working as a programmer being
>>> stuck at *that*.
>>
>> That simple check would require keeping a maximum of only N-1 entries 
>> in the N-position FIFO buffer, and the OP explicitly said they did not 
>> want to allocate an unused place in the buffer (which I think is 
>> unreasonable of the OP, but that is only IMO).
>>
>> The simple explanation for the N-1 limit is that the difference 
>> between two wrap-around pointers into an N-place buffer has at most N 
>> different values, while there are N+1 possible filling states of the 
>> buffer, from empty (zero items) to full (N items).
> 
> But, again, that just deals with the "full check".  The easiest way to do
> this is just to check ".in" *after* advancement and inhibit the store if
> it coincides with the ".out" value.
> 
> Checking for a "high water mark" to enable flow control requires more
> computation (albeit simple) as you have to accommodate the delays in
> that notification reaching the remote sender (lest he continue
> sending and overrun your buffer).
> 
> And, later noting when you've consumed enough of the FIFO's contents
> to reach a "low water mark" and reenable the remote's transmissions.
> 
> [And, if you ever have to deal with more "established" protocols
> that require the sequencing of specific control signals DURING
> a transfer, the ISR quickly becomes very complex!]


Of course. Perhaps you (Don) did not see that I was agreeing with your 
position and objecting to the "it is very simple" stance of Dimiter 
(considering the OP's expressed constraints).

Personally I would use critical sections to avoid relying on delicate 
reasoning about interleaved executions. And to allow for easy future 
complexification of the concurrent activities. The overhead of interrupt 
disabling and enabling is seldom significant when that can be done 
directly without kernel calls.

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

#30848

On 10/25/2021 2:06 AM, Niklas Holsti wrote:
> On 2021-10-25 11:28, Don Y wrote:
>> On 10/25/2021 1:09 AM, Niklas Holsti wrote:
>>> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>>>> On 10/24/2021 22:54, Don Y wrote:
>>>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>>>> alternatively you'll often get away not using a fifo at all,
>>>>>>> unless you're blocking for a long while in some part of the code.
>>>>>>
>>>>>> Why would you do that. The fifo write pointer is only modified by
>>>>>> the interrupt handler, the read pointer is only modified by the
>>>>>> interrupted code. Has been done so for times immemorial.
>>>>>
>>>>> The OPs code doesn't differentiate between FIFO full and empty.
>>>>
>>>> So he should fix that first, there is no sane reason why not.
>>>> Few things are simpler to do than that.
>>>
>>>
>>>     [snip]
>>>
>>>
>>>> Whatever handshakes he makes there is no problem knowing whether
>>>> the fifo is full - just check if the position the write pointer
>>>> will have after putting the next byte matches the read pointer
>>>> at the moment.  Like I said before, few things are simpler than
>>>> that, can't imagine someone working as a programmer being
>>>> stuck at *that*.
>>>
>>> That simple check would require keeping a maximum of only N-1 entries in the 
>>> N-position FIFO buffer, and the OP explicitly said they did not want to 
>>> allocate an unused place in the buffer (which I think is unreasonable of the 
>>> OP, but that is only IMO).
>>>
>>> The simple explanation for the N-1 limit is that the difference between two 
>>> wrap-around pointers into an N-place buffer has at most N different values, 
>>> while there are N+1 possible filling states of the buffer, from empty (zero 
>>> items) to full (N items).
>>
>> But, again, that just deals with the "full check".  The easiest way to do
>> this is just to check ".in" *after* advancement and inhibit the store if
>> it coincides with the ".out" value.
>>
>> Checking for a "high water mark" to enable flow control requires more
>> computation (albeit simple) as you have to accommodate the delays in
>> that notification reaching the remote sender (lest he continue
>> sending and overrun your buffer).
>>
>> And, later noting when you've consumed enough of the FIFO's contents
>> to reach a "low water mark" and reenable the remote's transmissions.
>>
>> [And, if you ever have to deal with more "established" protocols
>> that require the sequencing of specific control signals DURING
>> a transfer, the ISR quickly becomes very complex!]
> 
> Of course. Perhaps you (Don) did not see that I was agreeing with your position 
> and objecting to the "it is very simple" stance of Dimiter (considering the 
> OP's expressed constraints).

Yes, but I was afraid the emphasis would shift away from the "more involved"
case (by trivializing the "full" case).

> Personally I would use critical sections to avoid relying on delicate reasoning 
> about interleaved executions. And to allow for easy future complexification of 
> the concurrent activities. The overhead of interrupt disabling and enabling is 
> seldom significant when that can be done directly without kernel calls.

We (developers, in general) tend to forget how often we cobble
together solutions from past implementations.  And, as those past
implementations tend to be lax when it comes to enumerating the
assumptions under which they were created, we end up propagating
a bunch of dubious qualifiers that ultimately affect the code's
performance and "correctness".

Someone (including ourselves) trying to pilfer code from THIS
project might incorrectly expect the ISR to protect against buffer
wrap.  Or, implement flow control.  Or, be designed for a higher
data rate than it actually sees (saw!) -- will the buffer size -- and
task() timing -- be adequate to handle burst transmissions at 115Kbaud?
If not, where is the upper bound?  What if the CPU clock is changed?
Or, the processor load?  ...

"Steal" several bits of code -- possibly from different projects -- and
you've got an assortment of such hidden assumptions, all willing to eat
your lunch!   While you remain convinced that none of those things
can happen!

My first UART driver had to manage about a dozen control signals as
the standard had a different intent and interpretation in the mid 70's,
early 80's (anyone remember TWX?  TELEX?  DB25s?).  Porting it forward
ended up with a bunch of "issues" that no longer applied.  (e.g.,
RTS/CTS weren't originally used as flow control/handshaking signals as
they are commonly used, now).  *Assuming* a letter revision of the standard
was benign wrt the timing of signal transitions was folly.

You only see these things when you lay out all of your assumptions
in the codebase.  And, hope the next guy actually READS what you took
the time to WRITE!

[When I wrote my 9 track tape driver, I had ~200 lines of commentary
just explaining the role of the interface wrt the formatter, transports,
etc.  E.g., when you can read reverse, seek forward, rewind, etc.
with multiple transports hung off that same interface.  Otherwise,
an observant developer would falsely conclude that the driver was
riddled with bugs -- as it *facilitated* a multiplicity of
concurrent operations]

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

#30853

On 10/25/2021 11:09, Niklas Holsti wrote:
> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>> On 10/24/2021 22:54, Don Y wrote:
>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>> alternatively you'll often get away not using a fifo at all,
>>>>> unless you're blocking for a long while in some part of the code.
>>>>
>>>> Why would you do that. The fifo write pointer is only modified by
>>>> the interrupt handler, the read pointer is only modified by the
>>>> interrupted code. Has been done so for times immemorial.
>>>
>>> The OPs code doesn't differentiate between FIFO full and empty.
>>
>> So he should fix that first, there is no sane reason why not.
>> Few things are simpler to do than that.
> 
> 
>     [snip]
> 
> 
>> Whatever handshakes he makes there is no problem knowing whether
>> the fifo is full - just check if the position the write pointer
>> will have after putting the next byte matches the read pointer
>> at the moment.  Like I said before, few things are simpler than
>> that, can't imagine someone working as a programmer being
>> stuck at *that*.
> 
> That simple check would require keeping a maximum of only N-1 entries in 
> the N-position FIFO buffer, and the OP explicitly said they did not want 
> to allocate an unused place in the buffer (which I think is unreasonable 
> of the OP, but that is only IMO).

Well it might be reasonable if the fifo has a size of two, you know :-).

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

#30854

On 2021-10-25 16:04, Dimiter_Popoff wrote:
> On 10/25/2021 11:09, Niklas Holsti wrote:
>> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>>> On 10/24/2021 22:54, Don Y wrote:
>>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>>> alternatively you'll often get away not using a fifo at all,
>>>>>> unless you're blocking for a long while in some part of the code.
>>>>>
>>>>> Why would you do that. The fifo write pointer is only modified by
>>>>> the interrupt handler, the read pointer is only modified by the
>>>>> interrupted code. Has been done so for times immemorial.
>>>>
>>>> The OPs code doesn't differentiate between FIFO full and empty.
>>>
>>> So he should fix that first, there is no sane reason why not.
>>> Few things are simpler to do than that.
>>
>>
>>     [snip]
>>
>>
>>> Whatever handshakes he makes there is no problem knowing whether
>>> the fifo is full - just check if the position the write pointer
>>> will have after putting the next byte matches the read pointer
>>> at the moment.  Like I said before, few things are simpler than
>>> that, can't imagine someone working as a programmer being
>>> stuck at *that*.
>>
>> That simple check would require keeping a maximum of only N-1 entries 
>> in the N-position FIFO buffer, and the OP explicitly said they did not 
>> want to allocate an unused place in the buffer (which I think is 
>> unreasonable of the OP, but that is only IMO).
> 
> Well it might be reasonable if the fifo has a size of two, you know :-).


And if each of those two items is large, yes. But here we have a FIFO of 
8-bit characters... few programs are so tight on memory that they cannot 
stand one unused octet.

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

#30855

On 10/25/2021 8:34 AM, Niklas Holsti wrote:
> And if each of those two items is large, yes. But here we have a FIFO of 8-bit 
> characters... few programs are so tight on memory that they cannot stand one 
> unused octet.

It's not "unused".  Rather, it's roll is that of indicating "full/overrun".
The OP seems to have decided that this is of no concern -- in *one* app?

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

#30857

On 10/25/2021 20:43, Don Y wrote:
> On 10/25/2021 8:34 AM, Niklas Holsti wrote:
>> And if each of those two items is large, yes. But here we have a FIFO 
>> of 8-bit characters... few programs are so tight on memory that they 
>> cannot stand one unused octet.
> 
> It's not "unused".  Rather, it's roll is that of indicating "full/overrun".
> The OP seems to have decided that this is of no concern -- in *one* app?

Oh come on, I joked about the fifo of two bytes only because this whole
thread is a joke - pages and pages of C to maintain a fifo, what can be
more of a joke than this.

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

#30858

On 10/25/2021 10:53 AM, Dimiter_Popoff wrote:
> On 10/25/2021 20:43, Don Y wrote:
>> On 10/25/2021 8:34 AM, Niklas Holsti wrote:
>>> And if each of those two items is large, yes. But here we have a FIFO of 
>>> 8-bit characters... few programs are so tight on memory that they cannot 
>>> stand one unused octet.
>>
>> It's not "unused".  Rather, it's roll is that of indicating "full/overrun".
>> The OP seems to have decided that this is of no concern -- in *one* app?
> 
> Oh come on, I joked about the fifo of two bytes only because this whole
> thread is a joke

My comment applies regardless of the size of the FIFO.

> - pages and pages of C to maintain a fifo, what can be
> more of a joke than this.

Where do you see "pages and pages of C to maintain a FIFO"?

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

#30856

Il 25/10/2021 17:34, Niklas Holsti ha scritto:
> On 2021-10-25 16:04, Dimiter_Popoff wrote:
>> On 10/25/2021 11:09, Niklas Holsti wrote:
>>> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>>>> On 10/24/2021 22:54, Don Y wrote:
>>>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>>>> alternatively you'll often get away not using a fifo at all,
>>>>>>> unless you're blocking for a long while in some part of the code.
>>>>>>
>>>>>> Why would you do that. The fifo write pointer is only modified by
>>>>>> the interrupt handler, the read pointer is only modified by the
>>>>>> interrupted code. Has been done so for times immemorial.
>>>>>
>>>>> The OPs code doesn't differentiate between FIFO full and empty.
>>>>
>>>> So he should fix that first, there is no sane reason why not.
>>>> Few things are simpler to do than that.
>>>
>>>
>>>     [snip]
>>>
>>>
>>>> Whatever handshakes he makes there is no problem knowing whether
>>>> the fifo is full - just check if the position the write pointer
>>>> will have after putting the next byte matches the read pointer
>>>> at the moment.  Like I said before, few things are simpler than
>>>> that, can't imagine someone working as a programmer being
>>>> stuck at *that*.
>>>
>>> That simple check would require keeping a maximum of only N-1 entries 
>>> in the N-position FIFO buffer, and the OP explicitly said they did 
>>> not want to allocate an unused place in the buffer (which I think is 
>>> unreasonable of the OP, but that is only IMO).
>>
>> Well it might be reasonable if the fifo has a size of two, you know :-).
> 
> 
> And if each of those two items is large, yes. But here we have a FIFO of 
> 8-bit characters... few programs are so tight on memory that they cannot 
> stand one unused octet.

When I have a small (<256) power-of-two (16, 32, 64, 128) buffer (and 
this is the case for a UART receiving ring-buffer), I like to use this 
implementation that works and doesn't waste any element.

However I know this isn't the best implementation ever and it's a pity 
the thread emphasis has been against this implementation (that was used 
as *one* implementation just to have an example to discuss on).

The main point was the use of volatile (and other techniques) to 
guarantee a correct compiler output, whatever legal (respect the C 
standard) optimizations the compiler thinks to do.

It seems to me the arguments againts or for volatile are completely 
indipendent from the implementation of ring-buffer.

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

#30859

On 10/25/2021 10:52 AM, pozz wrote:
> However I know this isn't the best implementation ever and it's a pity the 
> thread emphasis has been against this implementation (that was used as *one* 
> implementation just to have an example to discuss on).

The point is that you need a COMPLETE implementation before you start
thinking about the amount of "license" the compiler can take with your code.

Here's *part* of an implementation:

       a = 37;

Now, should I declare A as volatile? Use the register qualifier?
What size should the integer A be?  Can the optimizer elide this
statement from my code?

All sorts of questions whose answers depend on the REST of the
implementation -- not shown!

> The main point was the use of volatile (and other techniques) to guarantee a 
> correct compiler output, whatever legal (respect the C standard) optimizations 
> the compiler thinks to do.
> 
> It seems to me the arguments againts or for volatile are completely indipendent 
> from the implementation of ring-buffer.

It has to do with indicating how YOU (the developer) see the object
being used (accessed).  You, in theory, know more about the role of
the object than the compiler (because it may be accessed in other modules,
or, have "stuff" tied to it -- like special hardware, etc.)  You need a way
to tell the compiler that "you know what you are doing" in your use
of the object and that it should restrain itself from making assumptions
that might not be true.

If your example doesn't bring to light those various issues, then
the decision as to its applicability is moot.

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

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

Back to top | Article view | comp.arch.embedded

csiph-web