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

Groups > comp.lang.c > #63568 > unrolled thread

Linked lists, message passing

Back to article view | Back to comp.lang.c

Contents

  Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 05:49 +0200
    Re: Linked lists, message passing Ike Naar <ike@iceland.freeshell.org> - 2015-06-19 06:51 +0000
      Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 09:08 +0200
        Re: Linked lists, message passing Barry Schwarz <schwarzb@dqel.com> - 2015-06-19 02:08 -0700
          Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 14:11 +0200
            Re: Linked lists, message passing raltbos@xs4all.nl (Richard Bos) - 2015-06-19 13:47 +0000
              Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 15:52 +0200
                Re: Linked lists, message passing Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:07 -0500
                Re: Linked lists, message passing raltbos@xs4all.nl (Richard Bos) - 2015-06-27 12:25 +0000
                  Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-06-29 09:03 +0200
                    Re: Linked lists, message passing raltbos@xs4all.nl (Richard Bos) - 2015-07-03 17:28 +0000
                      Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-07-03 22:16 +0200
                        Re: Linked lists, message passing Morris Dovey <mrdovey@iedu.com> - 2015-07-03 16:44 -0500
                          Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-07-04 01:12 +0200
                            Re: Linked lists, message passing Morris Dovey <mrdovey@iedu.com> - 2015-07-03 18:50 -0500
                              Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-07-04 09:39 +0200
                                Re: Linked lists, message passing Morris Dovey <mrdovey@iedu.com> - 2015-07-04 04:34 -0500
                                  Re: Linked lists, message passing Bartc <bc@freeuk.com> - 2015-07-04 11:01 +0100
                                    Re: Linked lists, message passing Geoff <geoff@invalid.invalid> - 2015-07-04 11:43 -0700
                                      Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-07-05 18:49 +0200
                                        Re: Linked lists, message passing Geoff <geoff@invalid.invalid> - 2015-07-05 12:30 -0700
                                          Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-07-05 22:39 +0200
                                            Re: Linked lists, message passing Geoff <geoff@invalid.invalid> - 2015-07-05 15:08 -0700
                                          Re: Linked lists, message passing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-06 01:05 +0000
                                            Re: Linked lists, message passing Geoff <geoff@invalid.invalid> - 2015-07-05 23:55 -0700
                                    Re: Linked lists, message passing "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-04 11:48 -0700
                            Re: Linked lists, message passing Morris Dovey <mrdovey@iedu.com> - 2015-07-03 18:51 -0500
                            Re: Linked lists, message passing G G <gdotone@gmail.com> - 2015-07-03 18:13 -0700
    Re: Linked lists, message passing Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 08:12 +0100
      Re: Linked lists, message passing "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 09:30 +0200
        Re: Linked lists, message passing Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 08:59 +0100
          Re: Linked lists, message passing Noob <root@127.0.0.1> - 2015-06-19 10:14 +0200
            Re: Linked lists, message passing Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 09:40 +0100
              Re: Linked lists, message passing Ian Collins <ian-news@hotmail.com> - 2015-06-20 15:14 +1200
      Re: Linked lists, message passing jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-19 18:10 +0200
        Re: Linked lists, message passing Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 17:32 +0100
          Re: Linked lists, message passing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-29 00:56 -0700
        Re: Linked lists, message passing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-29 00:49 -0700
      Re: Linked lists, message passing Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:32 -0700

Page 2 of 2 — ← Prev page 1 [2]

#64712

On Sun, 05 Jul 2015 18:49:47 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>On 04.07.2015 20:43, Geoff wrote:
>> On Sat, 04 Jul 2015 11:01:57 +0100, Bartc <bc@freeuk.com> wrote:
>>
>>> The first Z80 boards I had to build and debug were in my bedroom at
>>> home. All I had was a multimeter. Sometimes I used LEDs and a mirror
>>> that I flipped with my fingers, or I fed a logic signal into the video
>>> input of my B&W TV.
>>
>> That takes me back to the time I built and debugged a Z80-based
>> microcontroller wire-wrapped on two boards. I assembled the code on a
>> TRS-80 Model I, burned it to EPROM and debugged with a DVM and a
>> Tektronix oscilloscope. That system ran continuously for more than 20
>> years in a mountain-top radio repeater.
>
>That's cool.
>
>I got a reply from the QEMU list:
>
>"
>Peter Maydell <peter.maydell@linaro.org>
>[...]
>If you connect a gdb to QEMU's built in gdbstub, then you can do
>all of this with the usual gdb commands and UI :-)
>"
>
>Which is more than what I hoped for.  I looked at Minix 3 before
>the weekend, and it has a really small kernel.  Making my project
>run on a very small Minix setup could also help anchor the goal of
>making cross-platform C code.
>
>As for building long-running things, 20 years is cool.  Maybe my
>goal after building a simple CPU is to build a simple machine
>using just mechanical parts.. some day maybe, if I get the time. :)
>

Yes, it was a fun project. 20+ years was more than I expected from a
wire-wrap layout but I am told the life expectancy of properly done
wirewrap connections is very long. IIRC, the clock was 4MHz on the Z80
CPU. I drew the schematic on 1/4 inch ruled paper with a template and
pencil, there being no such thing as schematic capture at the time. It
was a DTMF controlled remote base and handled 4 radios.

The successor, and much more ambitious design was done in Accel Tango
on a Pentium PC and was implemented on STD Bus with a card interfacing
each radio. A single Z80 CPU card ran up to 16 radio interfaces with
an audio cross-bar switch to allow co-located remote base operations.
The OS was a priority-scheduled real-time system with inter-task
messaging written in C with some assembler for the bit fiddling in
some of the I/O. The entire system fit into 8kB of EPROM and 32kB of
RAM. The plan was to upgrade it to Z180 but I ran out of energy when
the demands of the day job exceeded my capacity. I still have the Z180
ICE I bought for the purpose. Like your mechanical project, maybe
someday...

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

#64720

On 05.07.2015 21:30, Geoff wrote:
> On Sun, 05 Jul 2015 18:49:47 +0200, "Morten W. Petersen"
[...]
>> As for building long-running things, 20 years is cool.  Maybe my
>> goal after building a simple CPU is to build a simple machine
>> using just mechanical parts.. some day maybe, if I get the time. :)
>>
>
> Yes, it was a fun project. 20+ years was more than I expected from a
> wire-wrap layout but I am told the life expectancy of properly done
> wirewrap connections is very long. IIRC, the clock was 4MHz on the Z80
> CPU. I drew the schematic on 1/4 inch ruled paper with a template and
> pencil, there being no such thing as schematic capture at the time. It
> was a DTMF controlled remote base and handled 4 radios.
>
> The successor, and much more ambitious design was done in Accel Tango
> on a Pentium PC and was implemented on STD Bus with a card interfacing
> each radio. A single Z80 CPU card ran up to 16 radio interfaces with
> an audio cross-bar switch to allow co-located remote base operations.
> The OS was a priority-scheduled real-time system with inter-task
> messaging written in C with some assembler for the bit fiddling in
> some of the I/O. The entire system fit into 8kB of EPROM and 32kB of
> RAM. The plan was to upgrade it to Z180 but I ran out of energy when
> the demands of the day job exceeded my capacity. I still have the Z180
> ICE I bought for the purpose. Like your mechanical project, maybe
> someday...

Hm, yes.  I have a breadboard and some stash lying around, but after
you mentioned wire-wrapping I looked up that and also found something
called "fritzing".

I think fritzing is the right place to start, then breadboard and then
wire-wrapping when creating a more robust prototype.

-Morten

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

#64725

On Sun, 05 Jul 2015 22:39:30 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>On 05.07.2015 21:30, Geoff wrote:
>> On Sun, 05 Jul 2015 18:49:47 +0200, "Morten W. Petersen"
>[...]
>>> As for building long-running things, 20 years is cool.  Maybe my
>>> goal after building a simple CPU is to build a simple machine
>>> using just mechanical parts.. some day maybe, if I get the time. :)
>>>
>>
>> Yes, it was a fun project. 20+ years was more than I expected from a
>> wire-wrap layout but I am told the life expectancy of properly done
>> wirewrap connections is very long. IIRC, the clock was 4MHz on the Z80
>> CPU. I drew the schematic on 1/4 inch ruled paper with a template and
>> pencil, there being no such thing as schematic capture at the time. It
>> was a DTMF controlled remote base and handled 4 radios.
>>
>> The successor, and much more ambitious design was done in Accel Tango
>> on a Pentium PC and was implemented on STD Bus with a card interfacing
>> each radio. A single Z80 CPU card ran up to 16 radio interfaces with
>> an audio cross-bar switch to allow co-located remote base operations.
>> The OS was a priority-scheduled real-time system with inter-task
>> messaging written in C with some assembler for the bit fiddling in
>> some of the I/O. The entire system fit into 8kB of EPROM and 32kB of
>> RAM. The plan was to upgrade it to Z180 but I ran out of energy when
>> the demands of the day job exceeded my capacity. I still have the Z180
>> ICE I bought for the purpose. Like your mechanical project, maybe
>> someday...
>
>Hm, yes.  I have a breadboard and some stash lying around, but after
>you mentioned wire-wrapping I looked up that and also found something
>called "fritzing".
>
>I think fritzing is the right place to start, then breadboard and then
>wire-wrapping when creating a more robust prototype.
>
That looks like a great place to start for small projects of less than
20 or 30 parts.

I used to prototype small projects in 1975 on breadboards as depicted
in the fritzing demos. We did small prototypes of the designs in
sections on 2 or 3 of those breadboards and tested them. Mostly analog
designs at that time in the shop I first worked in. I'd draw
schematics, breadboard the design, test, revise, retest. Once the
design was proved on the breadboards we passed the schematics to a
technician who laid out and taped up the PCB master on translucent
mylar in ruby red tape adhered to the mylar as a photographic master
of the PCB traces. The master was usually 2x or 4x the intended size.
A high-contrast 1:2 or 1:4 negative was then shot to be the mask for
exposing the photo-sensitive mask on the copper PCB. That shop was
limited to 2-layer designs.

When I did the STD Bus design on my own I did only two partial
prototypes on breadboard to prove my analog interface and the DTMF
decoder. The final board was a through-hole design with 6 layers of
copper, 4 trace layers and power and ground-plane layers, a top/bottom
solder mask, and a top silk screen for nomenclature and component ID.
The schematic was drawn in CAD then the component and netlist was
passed to the PCB program and the board was laid out and then routed
in an autorouter program, the autorouted board was fixed up in the PCB
program. The board had 183 components and the first batch of boards
was run through a local shop at a cost of about US$1600.00 in 1993. I
passed the CAM files to the PCB shop on 720k floppies. The platform
was Windows 3.1, Windows 95 and Windows NT 3.1 for the CAD and code
development tools. The design had two Gate Array Logic (GAL) circuits
on the board for glue. Engineering-wise the project was a success,
there were no flaws in the design, but commercially it was pointless.
It was a high-end repeater controller/conference bridge designed for a
niche market of a very small population of ham radio operators.

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

#64729

Geoff <geoff@invalid.invalid> wrote:

(snip)
> Yes, it was a fun project. 20+ years was more than I expected from a
> wire-wrap layout but I am told the life expectancy of properly done
> wirewrap connections is very long. IIRC, the clock was 4MHz on the Z80
> CPU. I drew the schematic on 1/4 inch ruled paper with a template and
> pencil, there being no such thing as schematic capture at the time. It
> was a DTMF controlled remote base and handled 4 radios.


I have been working with an IBM 2020 processor, built in 1967.
The backplane is PC board plus wirewrap, where easier lines go on
the PC board, and others that are too hard to route (in 1967 PC
routing technology) are wirewrap, I believe by machine. Likely many
more wrap connection points than yours, and still runs fine. 

Properly done, wirewrap is supposed to cold weld the contact points,
though hand wrapped might not be quite that good. 

The schematics for the 2020 are machine drawn and printed on
IBM line printers. Kind of ugly, but they do work.

-- glen

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

#64736

On Mon, 6 Jul 2015 01:05:15 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Geoff <geoff@invalid.invalid> wrote:
>
>(snip)
>> Yes, it was a fun project. 20+ years was more than I expected from a
>> wire-wrap layout but I am told the life expectancy of properly done
>> wirewrap connections is very long. IIRC, the clock was 4MHz on the Z80
>> CPU. I drew the schematic on 1/4 inch ruled paper with a template and
>> pencil, there being no such thing as schematic capture at the time. It
>> was a DTMF controlled remote base and handled 4 radios.
>
>
>I have been working with an IBM 2020 processor, built in 1967.
>The backplane is PC board plus wirewrap, where easier lines go on
>the PC board, and others that are too hard to route (in 1967 PC
>routing technology) are wirewrap, I believe by machine. Likely many
>more wrap connection points than yours, and still runs fine. 
>
>Properly done, wirewrap is supposed to cold weld the contact points,
>though hand wrapped might not be quite that good. 
>
>The schematics for the 2020 are machine drawn and printed on
>IBM line printers. Kind of ugly, but they do work.
>

The trick to a proper hand wrapped connection is learning not to press
too hard and cause an over-wrap of the wire onto itself, once you
learn that you can actually feel the tension of the wire as you wrap
it around the post. The stuff I used was 30 gage wire and you could
definitely tell when it was wrapping properly. Design life was
supposed to be 40 years or so. I had a power wrapping tool but I have
not seen it in years. It's probably in a box in the attic along side
the TRS-80.

The last "big" box I handled was a PDP-8A and it had a wire wrapped
back plane IIRC.

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

#64672

"Bartc"  wrote in message news:mn8as6$bgj$1@dont-email.me... 
[...]
> The first Z80 boards I had to build and debug were in my bedroom at 
> home. All I had was a multimeter. Sometimes I used LEDs and a mirror 
> that I flipped with my fingers, or I fed a logic signal into the video 
> input of my B&W TV.

IMHO, this is just another reason to love comp.lang.c!

:^)


BTW, this kind of reminds me of:

https://www.youtube.com/watch?v=cLy0mVkoLio

https://en.wikipedia.org/wiki/Jeri_Ellsworth

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

#64649

On 7/3/15 6:12 PM, Morten W. Petersen wrote:
> Earlier I've also thought about finding some (X86?) emulator that can
> give a full view of what's going on, there must be something like that
> out there.


-- 
Morris Dovey
http://www.iedu.com/Solar/
http://www.facebook.com/MorrisDovey

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

#64650

safecode.cs.illinois.edu/index.html

would this be of any help in a case like this one?

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

#63573

On 19/06/15 04:49, Morten W. Petersen wrote:

<snip>

> Can the struct be initialized using calloc or do I have to initialize
> everything to 0 myself?

The calloc function initialises allocated memory to all-bits-zero. This 
is nearly, but *not quite*, enough to guarantee that every initial value 
therein will also be zero. For example, there is no requirement on 
implementations to use the bit pattern all-bits-zero for null pointers 
(although they /are/ required to have a null pointer compare equal to 0, 
so if a null pointer /isn't/ all-bits-zero, they have to do some magic 
behind the scenes to make it all work).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63574

On 19.06.2015 09:12, Richard Heathfield wrote:
> On 19/06/15 04:49, Morten W. Petersen wrote:
>
> <snip>
>
>> Can the struct be initialized using calloc or do I have to initialize
>> everything to 0 myself?
>
> The calloc function initialises allocated memory to all-bits-zero. This
> is nearly, but *not quite*, enough to guarantee that every initial value
> therein will also be zero. For example, there is no requirement on
> implementations to use the bit pattern all-bits-zero for null pointers
> (although they /are/ required to have a null pointer compare equal to 0,
> so if a null pointer /isn't/ all-bits-zero, they have to do some magic
> behind the scenes to make it all work).

OK. I was thinking of security in particular, that calloc would
initialize everything and one could avoid old memory content "bleeding
into" new structures.

Googled a bit and found that both pointers and floating point variables
are an issue with calloc..

I'm thinking a good rule is to malloc a struct and then initialize it
to default values as a rule, and then for specific code that needs to
be super fast, don't initialize but make a note in the comment or
something that care should be taken.

-Morten

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

#63576

On 19/06/15 08:30, Morten W. Petersen wrote:

<snip>

> I'm thinking a good rule is to malloc a struct and then initialize it
> to default values as a rule, and then for specific code that needs to
> be super fast, don't initialize but make a note in the comment or
> something that care should be taken.

Generally, when allocating space for a struct I prefer to give it 
sensible values straight away. This isn't always possible, but at such 
times it's generally part of an array which is controlled by another 
struct, with mag and cap members (one gives the magnitude of the used 
part of the array, and the other gives the capacity of the array - any 
struct member with an index >= mag is assumed not to contain safe 
values). But if you want guaranteed default values, you could do it like 
this:

T *t_create(void)
{
   static const T template = {0};
   T *new = malloc(sizeof *new);
   if(new != NULL)
   {
     *new = template;
   }
   return new;
}

Unlike with calloc, the partial initialisation of an aggregate object 
/is/ guaranteed to provide you with the default initialisers for all the 
objects you didn't initialise explicitly (and 0 really will mean 0, 0.0, 
or a null pointer for T's first member).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63577

On 19/06/2015 09:59, Richard Heathfield wrote:

> T *t_create(void)
> {
>    static const T template = {0};
>    T *new = malloc(sizeof *new);
>    if(new != NULL)
>    {
>      *new = template;
>    }
>    return new;
> }

I suggest you throw a variable named 'class' in the mix ;-)

Regards.

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

#63582

On 19/06/15 09:14, Noob wrote:
> On 19/06/2015 09:59, Richard Heathfield wrote:
>
>> T *t_create(void)
>> {
>>    static const T template = {0};
>>    T *new = malloc(sizeof *new);
>>    if(new != NULL)
>>    {
>>      *new = template;
>>    }
>>    return new;
>> }
>
> I suggest you throw a variable named 'class' in the mix ;-)

Right. :-)

The choice of 'template' was in fact accidental. It was the obvious word 
to use (especially since the {0} could be modified to incorporate actual 
default values (and 'default' is a keyword, so obviously I couldn't use 
that), and it was only on re-reading when composing this reply that I 
noticed that it is in fact a keyword in Another Language.

But the choice of 'new' was entirely deliberate, and yes, it is 
specifically to prevent the code from being compiled under C++. If I 
want to use the code in C++, that's fine, but as a linked-in C module, 
not as C++. The purpose is to minimise any problems stemming from subtle 
differences in the semantics of the two languages (a situation that can 
only get worse as they both slowly evolve away from each other).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63655

Richard Heathfield wrote:
> On 19/06/15 09:14, Noob wrote:
>> On 19/06/2015 09:59, Richard Heathfield wrote:
>>
>>> T *t_create(void)
>>> {
>>>     static const T template = {0};
>>>     T *new = malloc(sizeof *new);
>>>     if(new != NULL)
>>>     {
>>>       *new = template;
>>>     }
>>>     return new;
>>> }
>>
>> I suggest you throw a variable named 'class' in the mix ;-)
>
> Right. :-)
>
> The choice of 'template' was in fact accidental. It was the obvious word
> to use (especially since the {0} could be modified to incorporate actual
> default values (and 'default' is a keyword, so obviously I couldn't use
> that), and it was only on re-reading when composing this reply that I
> noticed that it is in fact a keyword in Another Language.
>
> But the choice of 'new' was entirely deliberate, and yes, it is
> specifically to prevent the code from being compiled under C++. If I
> want to use the code in C++, that's fine, but as a linked-in C module,
> not as C++. The purpose is to minimise any problems stemming from subtle
> differences in the semantics of the two languages (a situation that can
> only get worse as they both slowly evolve away from each other).

One of the less than subtle differences (assigning a void* to a T*) 
would have prevented it from compiling without the gratuitous use of 
keywords :)

-- 
Ian Collins

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

#63616

Le 19/06/2015 09:12, Richard Heathfield a écrit :
> On 19/06/15 04:49, Morten W. Petersen wrote:
>
> <snip>
>
>> Can the struct be initialized using calloc or do I have to initialize
>> everything to 0 myself?
>
> The calloc function initialises allocated memory to all-bits-zero. This
> is nearly, but *not quite*, enough to guarantee that every initial value
> therein will also be zero. For example, there is no requirement on
> implementations to use the bit pattern all-bits-zero for null pointers
> (although they /are/ required to have a null pointer compare equal to 0,
> so if a null pointer /isn't/ all-bits-zero, they have to do some magic
> behind the scenes to make it all work).
>

I have just improved the performance of a package in lcc-win by 3% by 
just replacing calls to malloc followed by zeroing of the results by 
calling calloc.

As you (may) know, the zeroing of the memory is done more efficiently by 
specialized functions in the OS than by loops in user code.

So, by saying that calloc *could* make problems because some compiler 
could choose a non-zero value for NULL that would compare equal when 
compared to zero (!!!!!) you are giving away performance.

It is important to realize that there is no free lunch and that 
portability is COSTLY, specially portability to non-existing systems: I 
have never seen a system where NULL was different from zero.

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

#63620

On 19/06/15 17:10, jacobnavia wrote:
> Le 19/06/2015 09:12, Richard Heathfield a écrit :
>> On 19/06/15 04:49, Morten W. Petersen wrote:
>>
>> <snip>
>>
>>> Can the struct be initialized using calloc or do I have to initialize
>>> everything to 0 myself?
>>
>> The calloc function initialises allocated memory to all-bits-zero. This
>> is nearly, but *not quite*, enough to guarantee that every initial value
>> therein will also be zero. For example, there is no requirement on
>> implementations to use the bit pattern all-bits-zero for null pointers
>> (although they /are/ required to have a null pointer compare equal to 0,
>> so if a null pointer /isn't/ all-bits-zero, they have to do some magic
>> behind the scenes to make it all work).
>>
>
> I have just improved the performance of a package in lcc-win by 3% by
> just replacing calls to malloc followed by zeroing of the results by
> calling calloc.
>
> As you (may) know, the zeroing of the memory is done more efficiently by
> specialized functions in the OS than by loops in user code.
>
> So, by saying that calloc *could* make problems because some compiler
> could choose a non-zero value for NULL that would compare equal when
> compared to zero (!!!!!) you are giving away performance.

Right. And so you ask yourself, or I ask myself, or one asks oneself, 
how likely is it that my code will run on architectures where some 
all-bits-zero objects do not take their default static initialisers? If 
the answer is "very unlikely", you might well decide to trust calloc 
with your zeroing, which is fair enough. But if the answer is "very 
likely", then you will perhaps be less willing to do that.

The point is that the decision must be made, and from a position of 
knowledge about what is being traded off - in this case, portability vs 
performance - and why.

I do things in a slightly different way to you. Like you I use malloc, 
not calloc, but I give the object its correct value straight away 
wherever possible, thus completely eliminating the overhead of zeroing. 
Where that isn't possible (for example, where I am allocating an array 
of structs in anticipation of data I'll be reading in later), I use a 
convention like this:

struct foo
{
   size_t mag;
   size_t cap;
   T *p;
};

such that cap (capacity) is the number of Ts for which I have memory, 
and mag (magnitude) is the number of them that are currently in use. I 
thus know that if mag is 0 I don't have any data I can read, and if it's 
non-0 I know that I can trust p[0] to p[mag - 1] to have determinate 
values, but I can't trust p[mag] to p[cap - 1]. If I want to increase 
mag, I must therefore (a) check that mag < cap and, if need be, get more 
memory via realloc and extend cap, and (b) write to every element of 
p[mag] before doing ++mag.

>
> It is important to realize that there is no free lunch and that
> portability is COSTLY, specially portability to non-existing systems: I
> have never seen a system where NULL was different from zero.

Portability can indeed be costly, but so can non-portability. Systems 
where null pointers are not all-bits-zero do exist, and the fact that 
you haven't seen one is neither here nor there except as a data point.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#64426

On Friday, June 19, 2015 at 5:32:55 PM UTC+1, Richard Heathfield wrote:
> 
> Right. And so you ask yourself, or I ask myself, or one asks oneself, 
> how likely is it that my code will run on architectures where some 
> all-bits-zero objects do not take their default static initialisers? If 
> the answer is "very unlikely", you might well decide to trust calloc 
> with your zeroing, which is fair enough. But if the answer is "very 
> likely", then you will perhaps be less willing to do that.
> 
> The point is that the decision must be made, and from a position of 
> knowledge about what is being traded off - in this case, portability vs 
> performance - and why.
> 
I avoid calloc() as well. I'll memset to zero, to make it clear that
the memory is being zero-initialised deliberately. Also, calloc()
only makes sense if you are dynamically allocating an object that
has a starting position of all zero values. That's sometimes the
case, for example when plotting a histogram, but it's not the usual
situation, which is that the allocation starts out either empty
(that is, zero length as well as no data), or with data in it.

Then if allocations and zeroing are your bottleneck, you probably
shouldn't be using the malloc() family at all. Yes, you'll get a
bit of speed-up with calloc(), but you'll still have the overhead
of the calls to the allocation system. You need to rewrite the
program to use a fixed block allocator or a stack, if possible.

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

#64424

On Friday, June 19, 2015 at 5:10:50 PM UTC+1, jacobnavia wrote:
>
> As you (may) know, the zeroing of the memory is done more efficiently by 
> specialized functions in the OS than by loops in user code.
> 
> So, by saying that calloc *could* make problems because some compiler 
> could choose a non-zero value for NULL that would compare equal when 
> compared to zero (!!!!!) you are giving away performance.
> 
> It is important to realize that there is no free lunch and that 
> portability is COSTLY, specially portability to non-existing systems: I 
> have never seen a system where NULL was different from zero.
>
There are a few holes in the standard. calloc versus a-bits zero not
guaranteed to be NULL or floating point 0.0 is one of them. But
it's a difficult problem. It would be perfectly reasonable to produce
a floating point unit that used a two's complement exponent, and
reserved the extra negative slot for special cases. C can't sensibly
outlaw that. In fact I don;'t think there are any such processors
in production.

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

#65293

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 19/06/15 04:49, Morten W.  Petersen wrote:
>
> <snip>
>
>> Can the struct be initialized using calloc or do I have to initialize
>> everything to 0 myself?
>
> The calloc function initialises allocated memory to
> all-bits-zero.  This is nearly, but *not quite*, enough to guarantee
> that every initial value therein will also be zero.  For example, there
> is no requirement on implementations to use the bit pattern
> all-bits-zero for null pointers (although they /are/ required to have
> a null pointer compare equal to 0, so if a null pointer /isn't/
> all-bits-zero, they have to do some magic behind the scenes to make it
> all work).

Not really.  The 0 is converted to a null pointer before the
comparison is made.  So there isn't anything there beyond
what was needed to produce the null pointer in the first place.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web