Re: Asm source code page?

On 18 Jan 2016 10:18:46 -0800, you wrote:

> I have not visited here much of late - guess the lack of
> projects or new processors or laziness(?).

I've got it set up so that transactions here appear as email
events in my email, but automatically filed in a special
folder marked for what it is. All of the emails are also
sorted into threads, automatically, with responses indented
relative to those they are responding to (where possible.) I
can read, or not. But if I don't, a count gradually rises up
on the number of emails I've not yet looked at. So at some
point, I either just zero the count and ignore everything or
else I go take a look.

It doesn't require any more attention than I want to provide
at any given moment.

> Nice to Jon and Al- both of whom have given me invaluable
> help over the years.

Thanks!

> I use the IAR assembler tools as well. The are fast YACC
> based tools. I use them for the MSP430, 8051, and Renesas RX
> family.  Nice to be able to work with the same tools sets. 
> I don't use the IAR IDE at all nor their .h files. For every
> product, I create that defines every register, every bit and
> uses a fair amount of ASCII graphics. The idea behind this
> is that as an appendix, it follows the product and serves to
> complete the documentation.   The chief advantage I find is
> that you get a great exposure to the hardware and peripheral
> base that each processor family supports.  And like much
> code, it becomes the template for subsequent additions to
> that family.  The downside is that it takes a long time to
> create.  I am working on the RX family now and some members
> there have a huge number of configuration registers.

With contract work I do for customers, I let them tell me how
the development must go. I also ask them questions about the
future they see and let them know that C programmers (without
assembly coding experiences or with only modest experience
there) are easier to find than good, qualified assembly
programmers. So it may make a difference to them if they want
to replace me, later on. If they are as informed as I'm able
to make them and they still don't mind if I use assembly
coding then I consider the issue "up to me" and I make a
decision based upon what I imagine as mutual considerations
in balance.

If the project/product is my own (and I do that, as well)
then I usually will go to use assembly coding only. But not
always. If it is my product, I want to maximize my margins.
And this includes using the smallest/cheapest micro I can
manage. Even if I completely change the processor out, to a
completely different core (say, from MSP430 to PIC18), it's
not difficult for me to recode things quite quickly. There
are some significant differences when moving from a 16-bit
register core with "lots" of registers to an 8-bit core with
only a couple of registers. But in the process of recoding, I
also then find "opportunities" which again allow me to be
more competitive. I also face different power modes,
different trade-offs, etc. And I don't find all of that much
more difficult in assembly, than in C, say. So assembly
doesn't carry significant downsides. Also, in the early
stages of a new release of a micro, there usually will be an
assembler (or if not, it takes me almost no time at all to
adapt a table-based assembler tool to the new processor)
before there is a C compiler. In short, I often consider
assembly coding as not only a viable option, but a preferred
option when considering my own product development. But then,
I don't have any worries about finding a good assembler
programmer, either. ;)

> Everything is done from command line invocation in (ALT -
> F9) UltraEdit with the result box popping up in the editor.

Ah. Okay.

> My fallback assembler is the X32 Universal Assembler - a
> table driven product that allows you to define your own
> Mnemonics and Opcodes.

Hehe. I hadn't read this when discussing a table assembler
above! I see we think alike here, now.

> It can be expanded to add new
> instructions.  I did this to extend their H8 tables to
> support the H8S family - most notably the STM and LDM
> multiple stack push/pop instructions.  And it is very useful
> when porting code.   If I were more ambitious, I would
> create a Meta-Assembly language and then define the Opcodes
> for each member family.  Of course a good Macro capability
> in most assemblers can do the same thing.

Someone probably has already done this. Perhaps someone here
will point you (and me) to such a project!

Linkers which don't need to have specific intelligence (such
as being able to do link-time, optimized code generation),
should be quite general. You really only have two independent
memory achitecture models out there to support: von Neumann
and Harvard. And if you fully support the Harvard model, it's
trivial to support von Neumann. You to support named (and
unnamed, if you want) abstract segments, be able to combine
segments into groups (if you want), and be able to locate
them somehow. All the linker has to do is support a symbol
table, accept patch markers, and do a little "patching" of
the literal strings it sees.

There are some nice features in an assembler that I'd like
and I suppose those would take some work to achieve. But the
bottom line is that I would guess someone has taken on this
project already. I suppose I should go look and see. Maybe I
will.

> The real reason I code exclusively in assembler is that it
> reads better to me.  It matches my thinking and appears
> perfectly clear.  Maybe it is just a mental limitation of my
> part, but C is just too ugly to read and easily gets
> obfuscated beyond comprehension. 

I think "obfuscation" is largely a matter of familiarity with
the language and its idioms. (And a matter of who's writing
the code, of course -- new authors will often be far, far
more confusing in their code generation because they are NOT
familiar with the idioms nor are they very clear in their
thinking processes.) But I've been using C since 1978, so I'm
very comfortable with it. That said, for my projects, I still
will often use assembly language.

VB.NET, for example, is very intimidating for someone not
familiar with it. It can also be "almost familiar," too.

Here's an example that would be "familiar" even if you have
no real idea how it exactly achieves its purpose:

    Private Iterator Function Fibonacci() As IEnumerable
      Dim mA As Integer = 1
      Dim mB As Integer = 1
      Do
        Yield mA
        Dim r As Integer = mB
        mB += mA
        mA = r
      Loop
    End Function

Here's an example that would be more intimidating, even given
the idea that you already know what it might do given the
name of the function:

    Private Function Factorial(ByVal N As Integer) As Long
      Dim fset As Integer() =
        Enumerable.Range(2, N - 1).ToArray()
      Dim result As Long = 1
      Parallel.ForEach(Of Integer, Long)(
        fset,
        Function() As Long
          Return 1
        End Function,
        Function(item, s, sb)
          sb *= CLng(item)
          Return sb
        End Function,
        Sub(f)
          Dim v As Long = Interlocked.Exchange(result, 1)
          Do
            f *= v
            v = Interlocked.Exchange(result, f)
          Loop While v <> 1
        End Sub)
      Return result
    End Function

The above code spreads out the computations across multiple
cores. The function accepts an integer N and computes a long
result value. It's not difficult to read if you are familiar
with the idiom. But it's horrible if you aren't.

That said, writing the above code in assembly would be fairly
easy (perhaps easier) if you already had multi-core support
in your custom O/S. And the assembly code would probably be
easier to read and understand, too (my opinion.) So once
again it's a wash, or perhaps argues for assembly. But this
is a simple case of a trivial algorithm, too. So I don't make
too much of this, either way. Just mostly fun to look at for
a moment.

I think the main point is this. There is no "one answer that
fits all circumstances." Anyone who argues that assembly
coding is dead is, in my view, arguing from a narrow and
ignorant perspective. Anyone who argues that assembly coding
is always better is, similarly in my view, also arguing from
a narrow and ignorant perspective.

Details about circumstances matter.

A quality programmer will continually pursue the acquisition
addional skills. This means different language and their
semantics and syntax tradeoffs. This means mathematics. This
means electronics. This means optics. Cripes, I can even see
where it could include MIG welding, at times!

(I worked on developing a glass sorter which required optical
skills and electrical and electronic skills and welding
skills as well as programming skills. Being able to create
and setup simple experimental/test circumstances to explore
and validate different approaches at lower cost early in a
project can help in making sure that the final goals are
worthwhile and achievable before too much money is spent.)

I like to consider everything available and then, after I
understand the boundary conditions and goals well enough,
make choices. Having more skills than less means more choices
are available to consider. And that may mean the difference
between success and failure.

I think good assembly coding skills are one of the more
important programming skills for an embedded programmer to
get under their belt and with which to feel at home. But by
no means, the only such.

Jon

>Blakely LaCroix
>Minneapolis, Minnesota, USA


------------------------------------
Posted by: Jon Kirwan <[email protected]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[email protected]