filling remaining array elements with fixed value

Hi Tom,

On 6/28/2014 1:41 PM, Tom Gardner wrote:
> On 28/06/14 20:56, Don Y wrote:
>> On 6/26/2014 2:30 AM, Tom Gardner wrote:
>>
>>>> *All* of these processors were total *dogs* when it came to
>>>> HLL's! :<
>>>
>>> I'll disagree, for embedded systems at least. The code emitted
>>> by ?WhiteSmith's? C compiler for the Z80 was perfectly
>>> respectable. The only graunch I remember was i/o to a computed
>>> address having to be done by constructing the code on the stack,
>>> then executing it.
>>
>> The problem they all had was they were too small for HLL's.
>> Very few applications (even embedded) deal *exclusively* with
>> 8b data. So, lots of "helper" functions get drawn into the
>> executable -- to add/subtract/multiply/divide (even for integer
>> data). A *correct*/efficient printf(3c) could consume most of the
>> address space of these little processors!
>
> Sure. "Doctor, Doctor, my head hurts when I bang it against
> a wall". "Well, don't bang your head against walls, then".

If that's the only option you have, you're pretty much
stuck with it!

> We recoded putc() so that it did the minimal necessary
> on our system, and didn't use printf() (or did we write our
> own without FP support?; I can't remember)
>
> Anyway, who needs putc() on an embedded system if you have
> a decent ICE.

Um, you may need one if you do any sort of character based I/O!

> Apart from that, you just find ways of using the available
> technology to further your ends.
>
>> Support for multithreading
>> was entirely the user's responsibility (and, often not well facilitated
>> by the compiler).
>
> What multithreading support? There was none in C - it
> was explicitly stated by K&R to be a library issue. (And

And the libraries come from the compiler vendor!

Note that there are many things that the compiler can do that
will *prevent* you from implementing multithreading "in a
library".  This is especially true of smaller processors that
inevitably end up with lots of little "helper routines" that
are intimately tied to the compiler implementation.

E.g., __floating_add(), __long_signed_mul(), and, even things as
trivial as __long_add()!

Unless you have hooks that the compiler vendor provides and
guarantees for each of these things, there is nothing you can do
in your "runtime support" (different from "libraries") to
provide this.

> we'll overlook the embarrassing feature that libraries
> had to rely on language characteristics that C explicitly
> stated were undefined.)
>
> At least Z80s were so simple they didn't need a memory model!

Many Z80 systems employed banked memory.  The Z180 family of
devices had a funky *sort* of bank-switching.  The were even
TTL offerings (small RAMs) that were targeted to that sort of
application.

If you (not the compiler -- though I know of compilers that
could do this as well) are going to support these unnatural
(yet typical) sorts of environments, then you need to know
what implementation details the compiler is relying upon so
you don't, for example, swap the "floating point accumulator"
out of resident memory just before the compiler makes a
reference to it!

> So, we rolled our own cooperative multitasking RTOS using a
> few lines of assembler, which enabled us to program very
> naturally using something akin to co-routines.
>
> Same code (except teh ASM, natch) was used on many processors
> from PDP-11s to 8080s.

I built a UNIX-like execution environment.  Each "task" had its
own stdin/stdout/stderr; register context; C context (e.g.,
things like errno, reentrant strcspn(), etc.); floating point
context (along with a per-task switch that would allow the
RTOS to avoid saving/restoring the floating point context if
that task had no use for it); etc.

E.g., one application provided a curses-based user interface
over a serial port.  To implement this interface on *two*
serial ports, I simply spawned two tasks using the exact
same "task code":
     if0 = spawn(userIO, UART0, UART0, ERRORLOG);
     if1 = spawn(userIO, UART1, UART1, ERRORLOG);
(ERRORLOG was another "device" that just pushed whatever text
was written to it out the ICE to be displayed on the developer's
console.  In production code, the absence of the ICE hook caused
the text to be spooled to a small RAM buffer for post-mortems).
As each task had its own stack, autovariables, etc. they could
operate concurrently "for free".

Mutex support in the RTOS allows device I/O to seemlessly be
intertwined without requiring the developer to explicitly lock
and release a device.  So, ERRORLOG could contain entries like:
   taskD: ring detected
   taskD: answering
   taskA: waiting for user input
   taskD: building initial display image
   taskA: activating 'File' menu
   taskA: selecting 'SAVE AS' from 'File' menu
   taskD: waiting for user input
instead of:
   tasktaskAD: rianswering detectnged

>> It was usually pretty easy to look at an executable and *know* that
>> it was "compiled" -- the code was too rigid. I suspect this is
>> the reason for the "I can code better than the compiler" opinion
>> that was so prevalent -- because you often *could* (without
>> breaking into a sweat) especially if you were familiar with the
>> capabilities of the processor itself (e.g., do BCD math to
>> eliminate having to to a binary-to-decimal conversion, etc.)
>
> We stuck to plain old fixed point integers. I knew what floating
> point performance was like, having created a floating point library
> (inc sine/cosine) on a 6800 five years earlier in the mid 70s.

I've always used reduced precision floating point implementations.
"Templatize" the code and you can shrink to 24b floats, etc.  But,
you need the compiler vendor to cooperate with you.

You can implement printf(3c) in a modular form that allows only
those portions of the function that are going to be *used* to
be included in the link.  This isn't the sort of thing you would
worry about with bigger environments but can save many KB in a
small, e.g., 8-bitter.

>> Larger/more modern processors have more features geared directly
>> towards these HLL constructs. So, it is much more common to encounter
>> "clever code" from a *compiler* instead of an "ASM coder".

On 6/28/2014 11:53 PM, upsidedown@downunder.com wrote:
> On Sat, 28 Jun 2014 21:41:35 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk>  wrote:
>> On 28/06/14 20:56, Don Y wrote:
>
>>> Support for multithreading
>>> was entirely the user's responsibility (and, often not well facilitated
>>> by the compiler).
>>
>> What multithreading support? There was none in C - it
>> was explicitly stated by K&R to be a library issue. (And
>> we'll overlook the embarrassing feature that libraries
>> had to rely on language characteristics that C explicitly
>> stated were undefined.)
>
> It is of course a good question, how much multithreading/multitasking
> should be included in the language definition (such as ADA) and how
> much should be handled by calls to the underlaying OS.
>
> IMHO, the minimum requirement for a multithreading environment is that
> the generated code and libraries are (or at can be generated) as

------^^^^^^^^^^^^^^

This is the kicker.  You can replace a library relatively easily.
But, anything that the compiler itself relies upon gets to be a
touchy subject.  There are no contracts between the user and compiler
when it comes to the "guts" of the code and no hooks that you can
freely exploit that allow you to interject your operations amongst
those of the compiler.

Unless you force memory barriers, *in* your code AND have a way
for the compiler to let you know *where* it is wrt that code,
you can't go dicking around with the machine's state with
impunity.

> re-entrant code. Unfortunately the K&R definition makes this quite
> hard with some string etc. functions store some internal state in
> static variables. Then there is the issue with errno.

You can reimplement the standard libraries in a reentrant manner
(but, not a *portable* one -- unless you create some global
structs that you adopt in all implementations).  errno, as a
macro, can more easily be hacked based on the details of your
RTOS/MTOS:

static int task_id;
#define errno   int ERRNO[task_id]

Adopt the same sort of approach for any statics located in library
functions.

[I simply reimplement the libraries with more intimate ties to
the OS -- in essence, moving these things into the TCB]

> A similar problem had one Pascal compiler for 6809, which stored
> statically the so called "display" registers (base addresses for
> statically nested functions) in static locations, so there could just
> be one Pascal task, while the other tasks had to be written in
> assembly.
>
> For environments with program loaders, it is also nice to be able to
> use libraries which are position independent code, so that the code
> could be loaded into any free space.

On Sun, 29 Jun 2014 09:12:42 -0700, Don Y <this@is.not.me.com> wrote:

>Hi George,
>
>[small earthquake ~100 miles east last night.  Pretty lame, I
>imagine, as earthquakes go.  But, a first for me!  Cool!]
>
>On 6/27/2014 10:10 AM, George Neuner wrote:
>>> What annoys me about most FOSS is that most don't treat their
>>> "output" as a genuine (supportable) *product*.
>>
>> This shouldn't surprise you: it is traditional for hackers to release
>> (what they think are) "useful" programs into the wild and then forget
>> about them and move on to something else.  If you're not making money
>> from the project, apart from personal pride there's little incentive
>> to keep supporting it.
>
>Note that I didn't say "keep supporting it" -- I said produce a
>supportable product!  What they release isn't a product but,
>rather, a smattering of code that did what *they* wanted it to
>do (perhaps) -- for the effort they were willing to invest.

You're missing the point ... which is that that smattering of code did
what they wanted, so they thought "hey, it might be useful to someone
else".  The notion that their little hack is a "product" never occurs.

Return with us now to those days of yesteryear when there was a drawer
in the computer room filled with paper tapes, each containing
assembler source for a neat but completely undocumented program that
did who knows what.

Fast forward 50 years and the "drawer" now is called SourceForge (or
GitHub, or CodePlex, or whatever). 


>Now, imagine I had left the Scheme versions of these tools in the
>final build environment (LESS work for me as I wouldn't have to
>then create the C versions).

You could have compiled it to C.  If they can't reconstruct the
algorithm from mechanically translated code, they probably aren't
skilled enough to be playing with it in the first place.  8-)


>>> Yeah, I know... documentation and testing are "no fun".  But,
>>> presumably, you *want* people to use your "product" (even if it
>>> is FREE) so wouldn't you want to facilitate that?  I'm pretty
>>> sure folks don't want to throw lots of time and effort into something
>>> only to see it *not* used!
>>
>> That's a little harsh.  I don't think it's fair in general to expect
>> the same level of professionalism from part time developers as from
>> full time.
>
>But these same folks explain away the lack of testing and documentation
>in their "professional" efforts by blaming their PHB!  As if to say,
>"Yeah, I know.  I really wish I could do the formal testing and
>documentation that I, AS A PROFESSIONAL, know is representative of
>my PRODUCT... but, my boss just never gives me the time to do so...".
>
>There's no one forcing you to release YOUR CODE, now.  Or, forcing
>you to *stop* working on a test suite, documentation, etc. AFTER a
>"beta" release.  Yet, despite the opportunities to finish it up
>properly (the way you suggest you WISH you could to do in your 9-to-5),
>you, instead, lose interest and hope someone else cleans up the mess
>you've left.

You're still assuming that these efforts somehow are "professional".  

A formal statement of commitment to support raises my estimation of a
project, but I never assume anything is a professional effort unless I
am expected to pay $$$ to acquire it.



>Yes, most "software consumers" just want to know "which button do I
>press".  They don't want to understand the product.
>
>But, they would be just as happy with a CLOSED, PROPRIETARY solution
>released as a "free" binary!  (I.e., they just don't want to "spend
>money"!)  The whole point of FOSS is to enable others to modify and
>improve upon the initial work.  One would think you would want to
>facilitate this!

Back to the tape drawer analogy.



>> Sans a formal verification effort, it's almost impossible to guarantee
>> that a project of any size is bug free ... the best you can hope for
>> is that any bugs that are there are innocuous if they are triggered.
>
>You don't have to ensure "bug free".  But, you should be able to
>point to a methodical attempt undertaken by you -- and repeatable
>as well as augmentable by others -- that demonstrates the conditions
>that you have verified *in* your code base.  So, I can "suspect"
>a problem, examine your test cases and see (or NOT see) that you
>have (or have NOT) tested for that case before I waste additional
>time chasing a possibly unlikely issue.

Again you are assuming a "product".  In most cases, whatever it is
ISN'T A PRODUCT in the minds of its developer(s).



>It shouldn't matter whether you are worrying about stockholders or
>a life saved/lost.  Unless you are implicitly saying "this product
>isn't important... it doesn't HAVE TO WORK!  It has NO INTRINSIC
>VALUE -- because I make no guarantees that it does ANYTHING!".

"This generates those interesting licensing agreements in which the
vendor warrants nothing, not even that there is media on the disk,
while holding the buyer to line after line of restrictions on what he
can do with this thing he supposedly bought."
        -- Jerry Pournelle


>All I am asking the FOSS developer to do is *state* what he claims
>the value of his "product" to be.  And, show me why he believes
>that to be the case.

That's somewhat back-assward.

Software has no intrinsic value - any value YOU associate with it lies
completely in whether it performs some function YOU need.  It isn't up
to the developer to justify its creation, it is up to you to justify
your use of it and whether you are willing to pay the cost: in $$$, in
time, in frustration, etc. 

YMMV,
George

Hi George,

On 7/1/2014 7:33 AM, George Neuner wrote:

>> There's no one forcing you to release YOUR CODE, now.  Or, forcing
>> you to *stop* working on a test suite, documentation, etc. AFTER a
>> "beta" release.  Yet, despite the opportunities to finish it up
>> properly (the way you suggest you WISH you could to do in your 9-to-5),
>> you, instead, lose interest and hope someone else cleans up the mess
>> you've left.
>
> You're still assuming that these efforts somehow are "professional".

Well, I try to give folks the benefit of the doubt!  :>  I.e.,
they may not be *competent* but I *assume* their hearts are in the
right places!

> A formal statement of commitment to support raises my estimation of a
> project, but I never assume anything is a professional effort unless I
> am expected to pay $$$ to acquire it.

That's why I am gearing so much of my effort to allowing for
commercial exploitation -- ensuring the license doesn't drag
in any GPL-ish taint that would discourage a business entity
from embracing the code/hardware and "customizing it" (without
fear of having to share those "enhancements", fixes, etc.)

I.e., offer them something for their investment as *they*
will be expected to offer something to their *customers*!

>> Yes, most "software consumers" just want to know "which button do I
>> press".  They don't want to understand the product.
>>
>> But, they would be just as happy with a CLOSED, PROPRIETARY solution
>> released as a "free" binary!  (I.e., they just don't want to "spend
>> money"!)  The whole point of FOSS is to enable others to modify and
>> improve upon the initial work.  One would think you would want to
>> facilitate this!
>
> Back to the tape drawer analogy.

I guess I just do things differently.  There are very few things
that I invest time in and *save* that I don't also invest time
in documenting, testing, etc.  I just don't trust my memory
of what something *may* have done 1, 2, ... 20 years ago without
a paper trail.  If it isn't worth that effort, then I literally
*don't* save it!  (e.g., the scheme implementation of the "rule
converter" doesn't exist anywhere but my memory)

>>> Sans a formal verification effort, it's almost impossible to guarantee
>>> that a project of any size is bug free ... the best you can hope for
>>> is that any bugs that are there are innocuous if they are triggered.
>>
>> You don't have to ensure "bug free".  But, you should be able to
>> point to a methodical attempt undertaken by you -- and repeatable
>> as well as augmentable by others -- that demonstrates the conditions
>> that you have verified *in* your code base.  So, I can "suspect"
>> a problem, examine your test cases and see (or NOT see) that you
>> have (or have NOT) tested for that case before I waste additional
>> time chasing a possibly unlikely issue.
>
> Again you are assuming a "product".  In most cases, whatever it is
> ISN'T A PRODUCT in the minds of its developer(s).

Again, I keep (hoping to) give them the benefit of the doubt.
Yet, am not naive enough to ignore the perceived reality:

     "What they release isn't a product but, rather, a smattering
     of code that did what *they* wanted it to do (perhaps) -- for
     the effort they were willing to invest."

It would be like me releasing the scheme "hack" for the rule
converter thinking "it costs me nothing to publish it, maybe
someone will find it of use".

Instead, I take the attitude of releasing a more "finished" tool
that is *intended* to be supported (even if not by me!).  So, any
efforts in that light go into *the* tool and not the "earlier"
tool.  (keep efforts focused where I think they should be)

>> It shouldn't matter whether you are worrying about stockholders or
>> a life saved/lost.  Unless you are implicitly saying "this product
>> isn't important... it doesn't HAVE TO WORK!  It has NO INTRINSIC
>> VALUE -- because I make no guarantees that it does ANYTHING!".
>
> "This generates those interesting licensing agreements in which the
> vendor warrants nothing, not even that there is media on the disk,
> while holding the buyer to line after line of restrictions on what he
> can do with this thing he supposedly bought."
>          -- Jerry Pournelle

Yup.  I am convinced that you should never make any claims as
to what your hardware can do.  Put all the functionality in
the software/firmware.  Then, sell the product "with an included
disc" (USB stick, SD card, etc.) that represents a "suggested
application for this hardware" (even if it is the ONLY potential
application!).

Then, any problems can be shrugged off as "not warrantied".

>> All I am asking the FOSS developer to do is *state* what he claims
>> the value of his "product" to be.  And, show me why he believes
>> that to be the case.
>
> That's somewhat back-assward.

Why?  He should just release some code and let YOU decide what
you *think* it should do?  Give it a catchy name and *infer*
what it *might* do??

> Software has no intrinsic value - any value YOU associate with it lies
> completely in whether it performs some function YOU need.  It isn't up

By "value" I don't mean a numeric quantity.  Rather, this is why
I think this piece of code "solves a problem", "fills a need",
etc.  So I can *begin* to evaluate what it's *quantifiable* value
to me may be.

> to the developer to justify its creation, it is up to you to justify
> your use of it and whether you are willing to pay the cost: in $$$, in
> time, in frustration, etc.

My personal experience seems to "vote" increasingly for COTS tools
instead of FOSS "equivalents".  Each year I am willing to spend less
time dealing with tools that *hope* to work but still aren't
ready for prime time (e.g., claiming some "feature" only to discover
that it doesn't quite work -- yet!).

This despite being an early adopter of many FOSS solutions and
technologies.  (E.g., I was running X "apps" on my own machines
in the early-mid 80's).

Note, however, that I am equally unwilling to chase new COTS
releases "just to have the latest and greatest"!  Find a tool
that does what I *need*, then stick with it.  No need to invest
more time and money to "stay in the same place" (effectively).

I'm more interested in getting *my* projects done, now, than
helping others FINISH the loose ends on theirs...