Re: Asm source code page?

On Wed, 13 Jan 2016 00:20:52 -0800, you wrote:

>Wow, what a discussion I've sparked!

Well, most of us were just trying to clarify your question
and/or trying to be directly helpful. But "resonances" do
take place. ;)

>>5. Assembly is all they know, and they don't want to learn C.
>
>Bingo! I learned the bare essentials of assembler taking electronics 
>(digital specialty) at BCIT in 1974/1975.

I learned assembler in 1972. So right about the same time.

>I started by building microcomputers, which were hardly available at
>the time, from the chips.

Same here. And I learned still more late 1975 I think,
through hard won experience trying to diagnose and then fix
design problems in the Altair 8800's 4k dynamic RAM cards
(they WERE designed INCORRECTLY.)

>Never took programming per se,

I've also never taken a single class on programming, then or
since. I have, however, _taught_ computer science classes for
years at the largest 4-yr university in my state -- computer
architecture (2nd yr), assembly programming (2nd year),
operating systems (3rd yr), and concurrent programming (3rd
year.)

>but the computers were only 
>useful with software, so I developed my 6809 structured assembler and 
>a crude text editor for my 6809 based computer. And a 4800 baud 
>cassette interface for data storage - 4 times faster than any 
>commercial ones and more reliable.

Interesting. I designed and built a 600bps modem using a
6-pole transmit and a 10-pole receive filter in the 1970's.
The cassette interface I didn't do, but I suspect that it is
a somewhat less complex design. I do remember using one on
the first IBM PC (1983) which was included in the ROM BASIC
they provided and prior to that on the TRS-80, I think.

>I wrote among other things the first "Paint" program ever sold to the 
>public, "TV Graphics Editor" (1982) for Radio Shack Color Computer 
>(MC6809), and the world's first graphic adventure/role playing game, 
>"Viking Raider" (1984) for the Commodore 64. (Not a single untouched 
>256 byte block of memory remained, but I got everything in! About 150 
>screens of RLE map/scenery. Oh yah, the 6502 cross assembler that ran 
>on the Radio Shack CoCo for that project was another stuctured 
>assembler I wrote. I recall it only took 5 days to write, but it was 
>essentially just an adaptation of the 6809 version.)

This was around the time that I started a new business to
write and sell Winning on Wall Street for technical security
analysis and accounting for the Apple II and the IBM PC. Had
to write lots of drivers for newly arriving equipment and was
forced to use assembly coding on both machines for some of
the work (but not all, by any stretch.)

I don't remember your editor (didn't use the Radio Shack
computers that much at the time) or RPG (didn't use the C64
much either back then), though. Speaking of which, I have
BOXES of Commodore 64's and peripherals and manuals and
software here. One of these days I will need to figure out
what to do with all that stuff I've packed away.

>When I saw "Mac Paint" on the first Macintoshes, I thought they had 
>copied my "TV Graphics Editor", but there were enough differences 
>that I cancelled that thought, and I found out later that there was 
>an even earlier "Paint" program that had circulated in university 
>circles, on which Mac Paint was based.

Interesting.

>When I got into the 68K I started writing AKO really sophisticated 
>stuff, but I never got it to market.

I did do some applications on the 68020. But not many. I was
truly in love with the 88k, though. That was a nice looking
CPU architecture to my eye of that day.

>I dislike C.

I don't dislike it. I first was exposed to it while working
on Unix v6 in 1978 and really got to like it then. I've been
using it since.

>I have the hubris to think I (and I speak only for 
>myself) can do anything better and faster in assembler. ...with a 
>processor having a nice architecture and instruction set. From the 
>68K stuff on I've always tried to document and comment what I do very 
>fully. That's what will make the code easier for others to deal with 
>it later more than what language it's written in. I often find C very 
>hard to figure out just because it is so often sparcely commented - 
>also because the source is so often split into several or even many 
>files, which is of course a reflection of author philosophy or 'C 
>traditions' more than of the language itself.

Like anything else, we use the tools we know well when facing
tasks. I suspect that if you spent the time it takes to
become familiar with C, and learned how to hand-compile
assembly code from C source (you should be able to write
assembly code from C source almost as fast as you can write
-- it's actually quite easy), then you might enjoy it more.

For embedded use, it's my opinion that you really need to
thoroughly understand what a compiler "models" and what it
generates from the code you write. So if you type a line of
code, you should have a very good idea what it produces (you
should be able to do some of the optimizations quickly by
hand, as well.)

I had a really good time a few years ago when I got involved
in a debate between those who believed that modern x86/x64 C
compilers were far better than assembly programmers when
generating code. We did limit the challenge to local
optimizations over functions (not global, across them.) Two
of us engaged the "assembly side" of the project (which
lasted some months over the C newsgroup debate period.) I,
and my cohort, were able to produce assembly code that bested
the best compiler results by over a factor of 2 in speed and
by 30% in size, as well.

One of the lessons I learned from engaging this project is
that we humans can think in ways that NO COMPILER optimizer
can achieve, so far. The function was a simple one -- a
commonly found "greatest common divisor" function. The
solution for us was quite simple -- we "inverted" the
algorithm mentally which fit the x86 hardware better. No
compiler optimizer has ANY IDEA how to do that. And so far as
I'm aware, no one has even written a paper on how to
generalize the concept. I have some ideas how that might be
done. But... well, I don't have the spare time to pursue that
anymore.

We humans can be far, far more creative about what we can
apply and any finite set of compiler algorithms. What
compilers do REALLY WELL is "book-keeping" a large number of
things at once and in consistently applying principles over a
large set of code. Linkers have also developed substantially
in their intelligence, as well.

There is, I think, a bit of a sea-change ahead though. In the
case of these "multi-core" cpu systems regularly available
now, functional languages can offer some things that are much
more difficult to manage with imperative languages like C (or
assembly.) I'll give a trivial example using Haskel:

  factorial n = product [1..n]

This lets the compiler and operating system work out how to
spread this function's necessary multiplications across
multiple cores, automatically. A "partitioning" algorithm can
automatically use the number of available cores to break up
the set 1..n into separate pieces, which are then supplied to
the cores in isolation for the work to be performed. It can
then perform the final product from the pieces. And it can do
all of this differently on different machines, with different
values of n, and upon 2nd and 3rd invocations (as it can also
"learn" in the sense that the partitioner itself can observe
prior behavior of earlier partitions and develop better ones
over time.)

This problem didn't exist, years ago. But it will be an
increasing problem over time. These are difficult to achieve
with imperative languages, but of course not impossible. For
example, .NET under Windows does provide paritioning classes
for exactly this kind of purpose and now includes a
Parallel.For and Parallel.ForEach method. But the code does
have to be modified and tinkered with and even then it's not
quite so easy for a programmer to "get right."

At the assembly programming level, all this is of course also
possible. In fact, you've got ALL of the necessary semantics
available at the assembly level (some of which are NOT
entirely provided to high level compilers -- even C++.) So in
really critical cases, you are back to writing assembly code
even on massive-memory systems like today's workstations if
you truly need outstanding performance. But you usually
target yourself there for the high bandwidth stuff or where
languages simply do not provide the semantics.

There is a really good Ph.D. thesis book here:

http://www.cs.yale.edu/publications/techreports/tr364.pdf

which I read in 1985 when it came out. (I soon was working on
a MIPS R2000 board for the IBM PC.) You can see some
semantics there that still isn't available today on modern
compilers. So you can imagine how many more ideas also are
not present, as well. Compilers are VERY LIMITED in what
semantics they offer. The compensate this by being very good
at book-keeping and consistency.

>I'm not sure why I've typed all this. Now it's past bedtime and I 
>haven't done the work I meant to!

hehe!!

I'm very glad you did write! You very much clarified your
position as well as justifying my earlier writing to David
(which I couldn't have anticipated but am happy to have been
luckily more right than wrong about.)

Jon

>--Mr. Prejudiced
>
>PS: Hey, who swiped all my indents and spacings? (Rhetorical question) Grr!
>
>>test D1; SkipCS |BCS to end brace (BCS on 68K = JCS on MSP)
>>{
>>whatever
>>whatever more
>>dec D0; loopNE |BNE to start brace
>>}
>
>
>------------------------------------
>Posted by: Craig Carmichael <[email protected]>
>------------------------------------
>
>To unsubscribe from the msp430 group, send an email to:
>[email protected]
>
>
>------------------------------------
>
>Yahoo Groups Links
>
>
>


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

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