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

Groups > comp.sys.apple2.programmer > #6279 > unrolled thread

malloc with cc65

Back to article view | Back to comp.sys.apple2.programmer

Contents

  malloc with cc65 Bill Chatfield <bill_chatfield@yahoo.com> - 2023-12-14 13:53 -0500
    Re: malloc with cc65 Oliver Schmidt <ol.sc@web.de> - 2023-12-14 22:34 +0000
      Re: malloc with cc65 Bill Chatfield <bill_chatfield@yahoo.com> - 2023-12-14 21:59 -0500
        Re: malloc with cc65 Oliver Schmidt <ol.sc@web.de> - 2023-12-16 00:43 +0000
          Re: malloc with cc65 Bill Chatfield <bill_chatfield@yahoo.com> - 2023-12-18 00:58 -0500
            Re: malloc with cc65 Oliver Schmidt <ol.sc@web.de> - 2023-12-18 19:51 +0000
              Re: malloc with cc65 Bill Chatfield <bill_chatfield@yahoo.com> - 2023-12-20 10:52 -0500
                Re: malloc with cc65 Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2023-12-27 10:00 +1100
                  Re: malloc with cc65 Bill Chatfield <bill_chatfield@yahoo.com> - 2023-12-31 11:58 -0500
                    Re: malloc with cc65 Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-01-03 19:05 +1100
          Re: malloc with cc65 Colin Leroy-Mira <colin@colino.net> - 2024-02-01 21:54 +0100

#6279 — malloc with cc65

Can cc65 really build dynamically allocated data structures like a
vector or a map, or is it better to use a static implementation?

[toc] | [next] | [standalone]

#6280

Hi Bill,

> Can cc65 really build dynamically allocated data structures like a
> vector or a map, or is it better to use a static implementation?

1. cc65 comes with a fully functional heap manager incl. heap
defragmentation.

2. The cc65 optimizer (always compile with -O) knows about "pointer
constants" (in contrast to pointer variables) so the code to access them is
usually faster/smaller.

Regards,
Oliver

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

#6282

On Thu, 14 Dec 2023 22:34:07 -0000 (UTC)
Oliver Schmidt <ol.sc@web.de> wrote:

> 1. cc65 comes with a fully functional heap manager incl. heap
> defragmentation.

That is fantastic!
 
> 2. The cc65 optimizer (always compile with -O) knows about "pointer
> constants" (in contrast to pointer variables) so the code to access
> them is usually faster/smaller.

I'm not sure where a pointer constant would be used in a C program.
Would this be an address defined with #define or something like:
const char *KBD
?

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

#6283

Hi Bill,

>> 2. The cc65 optimizer (always compile with -O) knows about "pointer
>> constants" (in contrast to pointer variables) so the code to access
>> them is usually faster/smaller.

> I'm not sure where a pointer constant would be used in a C program.

I meant the term in this sense...

An integer variable:
int a

An integer constant:
5

Setting the variable to the constant:
a = 5

A pointer variable:
int *b

A pointer constant:
int c[10]

Setting the variable to the constant:
b = c

What I state above means that using c is faster/smaller than using b like
this:
*c = 2
*b = 2

Regards,
Oliver

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

#6284

On Sat, 16 Dec 2023 00:43:49 -0000 (UTC)
Oliver Schmidt <ol.sc@web.de> wrote:

> What I state above means that using c is faster/smaller than using b
> like this:
> *c = 2
> *b = 2

You're hard-coding the array into zero-page absolute address 2. Am I
understanding that correctly and is that what you meant?

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

#6285

Hi Bill,

>> What I state above means that using c is faster/smaller than using b
>> like this:
>> *c = 2
>> *b = 2
> 
> You're hard-coding the array into zero-page absolute address 2. Am I
> understanding that correctly and is that what you meant?

No, the syntax above isn't for assigning a value to a pointer. It's for
assigning a value to the address the pointer points to.

Regards,
Oliver

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

#6286

On Mon, 18 Dec 2023 19:51:58 -0000 (UTC)
Oliver Schmidt <ol.sc@web.de> wrote:

> No, the syntax above isn't for assigning a value to a pointer. It's
> for assigning a value to the address the pointer points to.

OMG, it's been too long since I've written C code. Of, course you're
right and I knew that. The overloading of the * operator in one place
to define a pointer and in another place, the exact opposite, to access
the data pointed to by a pointer, has always perplexed me.

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

#6289

Groovy hepcat Bill Chatfield was jivin' in comp.sys.apple2.programmer on
Thu, 21 Dec 2023 02:52 am. It's a cool scene! Dig it.

> On Mon, 18 Dec 2023 19:51:58 -0000 (UTC)
> Oliver Schmidt <ol.sc@web.de> wrote:
> 
>> No, the syntax above isn't for assigning a value to a pointer. It's
>> for assigning a value to the address the pointer points to.
> 
> OMG, it's been too long since I've written C code. Of, course you're
> right and I knew that. The overloading of the * operator in one place
> to define a pointer and in another place, the exact opposite, to
> access the data pointed to by a pointer, has always perplexed me.

  There's no overloading going on here (notwithstanding its use the
multiplication operator). It's really quite simple. The * operator
means "the object pointed at". When used in a declaration it still
means "the object pointed at". A pointer to foo (where foo is a type)
declaration essentially means, "Declare an object which is a pointer
such that the object pointed at by it is a foo."

-- 


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain't I'm a dawg!!

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

#6297

On Wed, 27 Dec 2023 10:00:43 +1100
Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:

>   There's no overloading going on here (notwithstanding its use the
> multiplication operator). It's really quite simple. The * operator
> means "the object pointed at". When used in a declaration it still
> means "the object pointed at". A pointer to foo (where foo is a type)
> declaration essentially means, "Declare an object which is a pointer
> such that the object pointed at by it is a foo."

I see what you're saying, after much mind bending. Maybe that is the
correct way to think about it.

The way I was thinking about it, in the declaration, the * produces a
pointer. In an expression the * produces data from a pointer.

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

#6301

Groovy hepcat Bill Chatfield was jivin' in comp.sys.apple2.programmer on
Mon, 1 Jan 2024 03:58 am. It's a cool scene! Dig it.

> On Wed, 27 Dec 2023 10:00:43 +1100
> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:
> 
>>   There's no overloading going on here (notwithstanding its use the
>> multiplication operator). It's really quite simple. The * operator
>> means "the object pointed at". When used in a declaration it still
>> means "the object pointed at". A pointer to foo (where foo is a type)
>> declaration essentially means, "Declare an object which is a pointer
>> such that the object pointed at by it is a foo."
> 
> I see what you're saying, after much mind bending. Maybe that is the
> correct way to think about it.
> 
> The way I was thinking about it, in the declaration, the * produces a
> pointer. In an expression the * produces data from a pointer.

  Dereferences the pointer, yeah, that's basically correct. But you have
to sort-of shift your thinking sideways a bit to understand what's
really going on. A declaration containing an asterisk means "declare an
object that points at foo". That's perhaps a more idiomatic but less
technically precise way of saying "declare an object which is a pointer
such that the object pointed at by it is a foo." The asterisk itself
means "the object pointed at".
  It may sound odd at first, but makes perfect sense once you get it. :)

-- 


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain't I'm a dawg!!

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

#6306

Hi,

>What I state above means that using c is faster/smaller than using b
>like this:
>*c = 2
>*b = 2

Unless you want to iterate, in which case 

while (*b) {
  ... do something with *b...
  b++;
}

is much faster than

while (c[i]) {
   ... do something with c[i]...
   i++;
}
-- 
Colin
https://www.colino.net/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web