From Newsgroup: comp.lang.c

Fwiw, I found some of my old code:

https://web.archive.org/web/20060214112603/http://appcore.home.comcast.net/appcore/include/cpu/i686/sys/ac_sys_i686_h.html

___________________
/* Copyright 2005 Chris Thomasson */


#ifndef AC_SYS_I686_H
#define AC_SYS_I686_H


#ifdef __cplusplus
extern "C"
{
#endif




#ifdef _MSC_VER
/* 4324: structure was padded due to _declspec(align()) */
#pragma warning ( disable : 4324 )
#endif


typedef struct
AC_DECLSPEC_ALIGN_CACHE_LINE
ac_i686_this_
{
ac_i686_stack_mpmc_t node_cache;
ac_i686_intword_t node_count;

} ac_i686_this_t;


#ifdef _MSC_VER
/* 4324: structure was padded due to _declspec(align()) */
#pragma warning ( default : 4324 )
#endif




AC_SYS_APIEXPORT int AC_APIDECL
ac_i686_startup
( ac_i686_this_t* );


AC_SYS_APIEXPORT int AC_APIDECL
ac_i686_shutdown
( void );


AC_SYS_APIEXPORT void AC_APIDECL
ac_i686_node_cache_flush
( void );


AC_SYS_APIEXPORT int AC_APIDECL
ac_i686_tls_alloc
( ac_i686_tls_t*,
ac_thread_t* );


AC_SYS_APIEXPORT int AC_APIDECL
ac_i686_tls_free
( ac_i686_tls_t* );




typedef ac_i686_this_t ac_cpu_this_t;

#define ac_cpu_tls_alloc ac_i686_tls_alloc
#define ac_cpu_tls_free ac_i686_tls_free
#define ac_cpu_startup ac_i686_startup
#define ac_cpu_shutdown ac_i686_shutdown
#define ac_cpu_node_cache_flush ac_i686_node_cache_flush




#ifdef __cplusplus
}
#endif


#endif


#include "ac_sys_i686_lfgc_smr.h"

___________________



Another abstraction: https://web.archive.org/web/20060214112519/http://appcore.home.comcast.net/appcore/include/cpu/i686/ac_i686_h.html
___________________
/* Copyright 2005 Chris Thomasson */


#ifndef AC_I686_H
#define AC_I686_H


#ifdef __cplusplus
extern "C"
{
#endif




/***** i686 Specific API *****/
#define AC_I686_CACHE_LINE 128
#define AC_I686_WORD_SIZE 4
#define AC_DECLSPEC_ALIGN_CACHE_LINE AC_DECLSPEC_ALIGN( AC_I686_CACHE_LINE )


#ifdef _MSC_VER
typedef signed __int32 ac_i686_intword_t;
typedef unsigned __int32 ac_i686_uintword_t;
typedef signed __int16 ac_i686_intword2_t;
typedef unsigned __int16 ac_i686_uintword2_t;
#define ac_i686_pause() _asm pause

#else
typedef signed int ac_i686_intword_t;
typedef unsigned int ac_i686_uintword_t;
typedef signed int short ac_i686_intword2_t;
typedef unsigned int short ac_i686_uintword2_t;
#define ac_i686_pause() __asm__ __volatile__ ( "pause" )
#endif


typedef ac_i686_uintword_t ac_i686_flags_t;


#define ac_i686_pause_yield() ac_i686_pause(); sched_yield()




#ifdef _MSC_VER
/* 4324: structure was padded due to __declspec(align()) */
#pragma warning ( disable : 4324 )
#pragma pack(1)
#endif

/* MUST be four adjacent words */
typedef struct
AC_DECLSPEC_PACKED
ac_i686_node_
{
struct ac_i686_node_ *next;
struct ac_i686_node_ *lfgc_next;
ac_fp_dtor_t fp_dtor;
const void *state;

} ac_i686_node_t;


/* MUST be two adjacent words. front must be at offset 0 */
typedef struct
AC_DECLSPEC_PACKED
ac_i686_stack_mpmc_
{
ac_i686_node_t *front;
ac_i686_uintword_t aba;

} ac_i686_stack_mpmc_t;


/* MUST be two adjacent words. front must be at offset 0 */
typedef struct
AC_DECLSPEC_PACKED
ac_i686_queue_spsc_
{
ac_i686_node_t *front;
ac_i686_node_t *back;

} ac_i686_queue_spsc_t;


/* MUST be two adjacent words */
typedef struct
AC_DECLSPEC_PACKED
ac_i686_tls_
{
struct ac_i686_lfgc_smr_ *lfgc_smr;
ac_thread_t *thread;

} ac_i686_tls_t;


#ifdef _MSC_VER
#pragma pack()
/* 4324: structure was padded due to __declspec(align()) */
#pragma warning ( default : 4324 )
#endif




/* critical i686 atomic api compile time assertion */
AC_BUILD_DBG_ASSERT
( i686,
sizeof( void* ) == AC_I686_WORD_SIZE &&
sizeof( ac_fp_dtor_t ) == AC_I686_WORD_SIZE &&
sizeof( ac_i686_node_t* ) == AC_I686_WORD_SIZE &&
sizeof( ac_i686_tls_t* ) == AC_I686_WORD_SIZE &&
sizeof( ac_i686_queue_spsc_t* ) == AC_I686_WORD_SIZE &&
sizeof( struct ac_i686_lfgc_smr_* ) == AC_I686_WORD_SIZE &&
sizeof( ac_thread_t* ) == AC_I686_WORD_SIZE &&
sizeof( ac_i686_intword_t ) == AC_I686_WORD_SIZE &&
sizeof( ac_i686_uintword_t ) == AC_I686_WORD_SIZE &&
sizeof( ac_i686_intword2_t ) == AC_I686_WORD_SIZE / 2 &&
sizeof( ac_i686_uintword2_t ) == AC_I686_WORD_SIZE / 2 &&
sizeof( ac_i686_node_t ) == AC_I686_WORD_SIZE * 4 &&
sizeof( ac_i686_queue_spsc_t ) == AC_I686_WORD_SIZE * 2 &&
sizeof( ac_i686_tls_t ) == AC_I686_WORD_SIZE * 2 &&
sizeof( ptrdiff_t ) == AC_I686_WORD_SIZE &&
sizeof( size_t ) == AC_I686_WORD_SIZE );




AC_SYS_APIEXPORT
void AC_CDECL
ac_i686_mb_fence
( void );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_mb_load_fence
( ac_i686_intword_t* );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_mb_store_fence
( ac_i686_intword_t*,
ac_i686_intword_t );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_mb_load_naked
( ac_i686_intword_t* );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_mb_store_naked
( ac_i686_intword_t*,
ac_i686_intword_t );


AC_SYS_APIEXPORT
int AC_CDECL
np_ac_i686_atomic_dwcas_fence
( void*,
void*,
const void* );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_atomic_cas_fence
( ac_i686_intword_t*,
ac_i686_intword_t,
ac_i686_intword_t );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_atomic_xchg_fence
( ac_i686_intword_t*,
ac_i686_intword_t );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_atomic_xadd_fence
( ac_i686_intword_t*,
ac_i686_intword_t );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_atomic_inc_fence
( ac_i686_intword_t* );


AC_SYS_APIEXPORT
ac_i686_intword_t AC_CDECL
ac_i686_atomic_dec_fence
( ac_i686_intword_t* );


AC_SYS_APIEXPORT void AC_CDECL
ac_i686_stack_mpmc_push_cas
( ac_i686_stack_mpmc_t*,
ac_i686_node_t* );


AC_SYS_APIEXPORT ac_i686_node_t* AC_CDECL
np_ac_i686_stack_mpmc_pop_dwcas
( ac_i686_stack_mpmc_t* );


AC_SYS_APIEXPORT void AC_CDECL
ac_i686_queue_spsc_push
( ac_i686_queue_spsc_t*,
ac_i686_node_t* );


AC_SYS_APIEXPORT ac_i686_node_t* AC_CDECL
ac_i686_queue_spsc_pop
( ac_i686_queue_spsc_t* );


AC_APIEXPORT ac_i686_node_t* AC_APIDECL
ac_i686_node_cache_pop
( const void *state );


AC_APIEXPORT void AC_APIDECL
ac_i686_node_cache_push
( ac_i686_node_t* );


AC_APIEXPORT int AC_APIDECL
ac_i686_node_cache_push_no_free
( ac_i686_node_t* );




#define ac_i686_stack_mpmc_init( ac_macro_this ) \
(ac_macro_this)->front = 0


#define ac_i686_queue_spsc_init( ac_macro_this, ac_macro_dummy ) \
(ac_macro_this)->front = (ac_macro_dummy); \
(ac_macro_this)->back = (ac_macro_dummy)


#define ac_i686_node_init( ac_macro_this, ac_macro_fp_dtor,
ac_macro_state ) \
(ac_macro_this)->next = 0; \
(ac_macro_this)->lfgc_next = 0; \
(ac_macro_this)->fp_dtor = (ac_macro_fp_dtor); \
(ac_macro_this)->state = (ac_macro_state)


#define ac_i686_node_get_next( ac_macro_this ) \
( (ac_macro_this)->next )


#define ac_i686_mb_node_get_next( ac_macro_this ) \
( (ac_i686_node_t*)ac_mb_loadptr_depends( &(ac_macro_this)->next ) )


#define ac_i686_node_get_state( ac_macro_this ) \
( (void*)(ac_macro_this)->state )


#define ac_i686_mb_node_get_state( ac_macro_this ) \
( ac_mb_loadptr_depends( &(ac_macro_this)->state ) )


#define ac_i686_mb_loadptr_fence( ac_macro_state ) \
( (void*)ac_i686_mb_load_fence \
( (ac_i686_intword_t*)(ac_macro_state) ) )


#define ac_i686_mb_loadptr_naked( ac_macro_state ) \
( (void*)ac_i686_mb_load_naked \
( (ac_i686_intword_t*)(ac_macro_state) ) )


#define ac_i686_mb_storeptr_fence( ac_macro_dest, ac_macro_state ) \
( (void*)ac_i686_mb_store_fence \
( (ac_i686_intword_t*)(ac_macro_dest), \
(ac_i686_intword_t)(ac_macro_state) ) )


#define ac_i686_mb_storeptr_naked( ac_macro_dest, ac_macro_state ) \
( (void*)ac_i686_mb_store_naked \
( (ac_i686_intword_t*)(ac_macro_dest), \
(ac_i686_intword_t)(ac_macro_state) ) )


#define ac_i686_atomic_casptr_fence( ac_macro_dest, ac_macro_cmp, ac_macro_xchg ) \
( (void*)ac_i686_atomic_cas_fence \
( (ac_i686_intword_t*)(ac_macro_dest), \
(ac_i686_intword_t)(ac_macro_cmp), \
(ac_i686_intword_t)(ac_macro_xchg) ) )


#define ac_i686_atomic_xchgptr_fence( ac_macro_dest, ac_macro_xchg ) \
( (void*)ac_i686_atomic_xchg_fence \
( (ac_i686_intword_t*)(ac_macro_dest), \
(ac_i686_intword_t)(ac_macro_xchg) ) )








/***** Low-Level Atomic API Abstraction *****/
#define AC_CPU_CACHE_LINE AC_I686_CACHE_LINE
#define AC_CPU_WORD_SIZE AC_I686_WORD_SIZE


#ifndef AC_CPU_HAS_DWCAS
#define AC_CPU_HAS_DWCAS
#endif




typedef ac_i686_intword_t ac_intword_t;
typedef ac_i686_uintword_t ac_uintword_t;
typedef ac_i686_intword2_t ac_intword2_t;
typedef ac_i686_uintword2_t ac_uintword2_t;
typedef ac_i686_flags_t ac_flags_t;


typedef ac_i686_node_t ac_cpu_node_t;
typedef ac_i686_stack_mpmc_t ac_cpu_stack_mpmc_t;
typedef ac_i686_queue_spsc_t ac_cpu_queue_spsc_t;
typedef ac_i686_tls_t ac_cpu_tls_t;




#define ac_cpu_pause ac_i686_pause
#define ac_cpu_pause_yield ac_i686_pause_yield


#define ac_mb_fence ac_i686_mb_fence


#define ac_mb_load_fence ac_i686_mb_load_fence
#define ac_mb_load_naked ac_i686_mb_load_naked
#define ac_mb_load_acquire ac_mb_load_naked
#define ac_mb_load_depends ac_mb_load_naked
#define ac_mb_loadptr_fence ac_i686_mb_loadptr_fence
#define ac_mb_loadptr_naked ac_i686_mb_loadptr_naked
#define ac_mb_loadptr_acquire ac_mb_loadptr_naked
#define ac_mb_loadptr_depends ac_mb_loadptr_naked


#define ac_mb_store_fence ac_i686_mb_store_fence
#define ac_mb_store_naked ac_i686_mb_store_naked
#define ac_mb_store_release ac_mb_store_naked
#define ac_mb_storeptr_fence ac_i686_mb_storeptr_fence
#define ac_mb_storeptr_naked ac_i686_mb_storeptr_naked
#define ac_mb_storeptr_release ac_mb_storeptr_naked


#define np_ac_atomic_dwcas_fence np_ac_i686_atomic_dwcas_fence
#define np_ac_atomic_dwcas_acquire np_ac_atomic_dwcas_fence
#define np_ac_atomic_dwcas_release np_ac_atomic_dwcas_fence
#define np_ac_atomic_dwcas_depends np_ac_atomic_dwcas_fence


#define ac_atomic_cas_fence ac_i686_atomic_cas_fence
#define ac_atomic_cas_acquire ac_atomic_cas_fence
#define ac_atomic_cas_release ac_atomic_cas_fence
#define ac_atomic_cas_depends ac_atomic_cas_fence
#define ac_atomic_casptr_fence ac_i686_atomic_casptr_fence
#define ac_atomic_casptr_acquire ac_atomic_casptr_fence
#define ac_atomic_casptr_release ac_atomic_casptr_fence
#define ac_atomic_casptr_depends ac_atomic_casptr_fence


#define ac_atomic_xadd_fence ac_i686_atomic_xadd_fence
#define ac_atomic_xadd_acquire ac_atomic_xadd_fence
#define ac_atomic_xadd_release ac_atomic_xadd_fence
#define ac_atomic_xadd_depends ac_atomic_xadd_fence


#define ac_atomic_xchg_fence ac_i686_atomic_xchg_fence
#define ac_atomic_xchg_acquire ac_atomic_xchg_fence
#define ac_atomic_xchg_release ac_atomic_xchg_fence
#define ac_atomic_xchg_depends ac_atomic_xchg_fence
#define ac_atomic_xchgptr_fence ac_i686_atomic_xchgptr_fence
#define ac_atomic_xchgptr_acquire ac_atomic_xchgptr_fence
#define ac_atomic_xchgptr_release ac_atomic_xchgptr_fence
#define ac_atomic_xchgptr_depends ac_atomic_xchgptr_fence


#define ac_atomic_inc_fence ac_i686_atomic_inc_fence
#define ac_atomic_inc_acquire ac_atomic_inc_fence
#define ac_atomic_inc_release ac_atomic_inc_fence
#define ac_atomic_inc_depends ac_atomic_inc_fence


#define ac_atomic_dec_fence ac_i686_atomic_dec_fence
#define ac_atomic_dec_acquire ac_atomic_dec_fence
#define ac_atomic_dec_release ac_atomic_dec_fence
#define ac_atomic_dec_depends ac_atomic_dec_fence


#define ac_cpu_queue_spsc_init ac_i686_queue_spsc_init
#define ac_cpu_queue_spsc_push ac_i686_queue_spsc_push
#define ac_cpu_queue_spsc_pop ac_i686_queue_spsc_pop


#define ac_cpu_stack_mpmc_init ac_i686_stack_mpmc_init
#define ac_cpu_stack_mpmc_push_cas ac_i686_stack_mpmc_push_cas
#define np_ac_cpu_stack_mpmc_pop_dwcas np_ac_i686_stack_mpmc_pop_dwcas


#define ac_cpu_node_init ac_i686_node_init
#define ac_cpu_node_get_next ac_i686_node_get_next
#define ac_cpu_mb_node_get_next ac_i686_mb_node_get_next
#define ac_cpu_node_get_state ac_i686_node_get_state
#define ac_cpu_mb_node_get_state ac_i686_mb_node_get_state
#define ac_cpu_node_cache_pop ac_i686_node_cache_pop
#define ac_cpu_node_cache_push ac_i686_node_cache_push
#define ac_cpu_node_cache_push_no_free ac_i686_node_cache_push_no_free





#ifdef __cplusplus
}
#endif


#endif




#include "ac_i686_lfgc_smr.h"
#include "ac_i686_lfgc_refcount.h"

___________________





--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/21/2026 2:06 PM, Dan Cross wrote:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

Is this commonly used, Kosher? Its from some really old code of mine.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/21/2026 2:06 PM, Dan Cross wrote:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

Is this commonly used, Kosher? Its from some really old code of mine.

Is *what* commonly used? What part of your 500+ lines of C code
are you asking about?

It appears to be two different *.h files. The first one appears
to depend on some macros that are defined in another header, but
it has no #include directives.

It's not worth my time to dig into it any further.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/21/2026 5:36 PM, Keith Thompson wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/21/2026 2:06 PM, Dan Cross wrote:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

Is this commonly used, Kosher? Its from some really old code of mine.

Is *what* commonly used? What part of your 500+ lines of C code
are you asking about?

It appears to be two different *.h files. The first one appears
to depend on some macros that are defined in another header, but
it has no #include directives.

It's not worth my time to dig into it any further.

Say, this part:


/***** Low-Level Atomic API Abstraction *****/
#define AC_CPU_CACHE_LINE AC_I686_CACHE_LINE
#define AC_CPU_WORD_SIZE AC_I686_WORD_SIZE


#ifndef AC_CPU_HAS_DWCAS
#define AC_CPU_HAS_DWCAS
#endif




typedef ac_i686_intword_t ac_intword_t;
typedef ac_i686_uintword_t ac_uintword_t;
typedef ac_i686_intword2_t ac_intword2_t;
typedef ac_i686_uintword2_t ac_uintword2_t;
typedef ac_i686_flags_t ac_flags_t;


typedef ac_i686_node_t ac_cpu_node_t;
typedef ac_i686_stack_mpmc_t ac_cpu_stack_mpmc_t;
typedef ac_i686_queue_spsc_t ac_cpu_queue_spsc_t;
typedef ac_i686_tls_t ac_cpu_tls_t;




#define ac_cpu_pause ac_i686_pause
#define ac_cpu_pause_yield ac_i686_pause_yield


#define ac_mb_fence ac_i686_mb_fence


#define ac_mb_load_fence ac_i686_mb_load_fence
#define ac_mb_load_naked ac_i686_mb_load_naked
#define ac_mb_load_acquire ac_mb_load_naked
#define ac_mb_load_depends ac_mb_load_naked
#define ac_mb_loadptr_fence ac_i686_mb_loadptr_fence
#define ac_mb_loadptr_naked ac_i686_mb_loadptr_naked
#define ac_mb_loadptr_acquire ac_mb_loadptr_naked
#define ac_mb_loadptr_depends ac_mb_loadptr_naked


#define ac_mb_store_fence ac_i686_mb_store_fence
#define ac_mb_store_naked ac_i686_mb_store_naked
#define ac_mb_store_release ac_mb_store_naked
#define ac_mb_storeptr_fence ac_i686_mb_storeptr_fence
#define ac_mb_storeptr_naked ac_i686_mb_storeptr_naked
#define ac_mb_storeptr_release ac_mb_storeptr_naked


#define np_ac_atomic_dwcas_fence np_ac_i686_atomic_dwcas_fence
#define np_ac_atomic_dwcas_acquire np_ac_atomic_dwcas_fence
#define np_ac_atomic_dwcas_release np_ac_atomic_dwcas_fence
#define np_ac_atomic_dwcas_depends np_ac_atomic_dwcas_fence


#define ac_atomic_cas_fence ac_i686_atomic_cas_fence
#define ac_atomic_cas_acquire ac_atomic_cas_fence
#define ac_atomic_cas_release ac_atomic_cas_fence
#define ac_atomic_cas_depends ac_atomic_cas_fence
#define ac_atomic_casptr_fence ac_i686_atomic_casptr_fence
#define ac_atomic_casptr_acquire ac_atomic_casptr_fence
#define ac_atomic_casptr_release ac_atomic_casptr_fence
#define ac_atomic_casptr_depends ac_atomic_casptr_fence


#define ac_atomic_xadd_fence ac_i686_atomic_xadd_fence
#define ac_atomic_xadd_acquire ac_atomic_xadd_fence
#define ac_atomic_xadd_release ac_atomic_xadd_fence
#define ac_atomic_xadd_depends ac_atomic_xadd_fence


#define ac_atomic_xchg_fence ac_i686_atomic_xchg_fence
#define ac_atomic_xchg_acquire ac_atomic_xchg_fence
#define ac_atomic_xchg_release ac_atomic_xchg_fence
#define ac_atomic_xchg_depends ac_atomic_xchg_fence
#define ac_atomic_xchgptr_fence ac_i686_atomic_xchgptr_fence
#define ac_atomic_xchgptr_acquire ac_atomic_xchgptr_fence
#define ac_atomic_xchgptr_release ac_atomic_xchgptr_fence
#define ac_atomic_xchgptr_depends ac_atomic_xchgptr_fence


#define ac_atomic_inc_fence ac_i686_atomic_inc_fence
#define ac_atomic_inc_acquire ac_atomic_inc_fence
#define ac_atomic_inc_release ac_atomic_inc_fence
#define ac_atomic_inc_depends ac_atomic_inc_fence


#define ac_atomic_dec_fence ac_i686_atomic_dec_fence
#define ac_atomic_dec_acquire ac_atomic_dec_fence
#define ac_atomic_dec_release ac_atomic_dec_fence
#define ac_atomic_dec_depends ac_atomic_dec_fence


#define ac_cpu_queue_spsc_init ac_i686_queue_spsc_init
#define ac_cpu_queue_spsc_push ac_i686_queue_spsc_push
#define ac_cpu_queue_spsc_pop ac_i686_queue_spsc_pop


#define ac_cpu_stack_mpmc_init ac_i686_stack_mpmc_init
#define ac_cpu_stack_mpmc_push_cas ac_i686_stack_mpmc_push_cas
#define np_ac_cpu_stack_mpmc_pop_dwcas np_ac_i686_stack_mpmc_pop_dwcas


#define ac_cpu_node_init ac_i686_node_init
#define ac_cpu_node_get_next ac_i686_node_get_next
#define ac_cpu_mb_node_get_next ac_i686_mb_node_get_next
#define ac_cpu_node_get_state ac_i686_node_get_state
#define ac_cpu_mb_node_get_state ac_i686_mb_node_get_state
#define ac_cpu_node_cache_pop ac_i686_node_cache_pop
#define ac_cpu_node_cache_push ac_i686_node_cache_push
#define ac_cpu_node_cache_push_no_free ac_i686_node_cache_push_no_free


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10uoril$197kd$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/21/2026 5:36 PM, Keith Thompson wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/21/2026 2:06 PM, Dan Cross wrote:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

Is this commonly used, Kosher? Its from some really old code of mine.

Is *what* commonly used? What part of your 500+ lines of C code
are you asking about?

It appears to be two different *.h files. The first one appears
to depend on some macros that are defined in another header, but
it has no #include directives.

It's not worth my time to dig into it any further.

Say, this part:

[snip many lines of random typedefs and macros]

...you posted over a hundred lines of nothing but preprocessor
macros and typedefs, absent any kind of context.

Regardless, no, none of that is commonly used. Please don't
respond with some pointless question like, "don't people use
atomic operations?" or something vague and divorced from what
you are actually posting. For that matter, please don't post
any code that isn't accompanied by a specific, well-worded
question about that code.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/22/2026 10:42 AM, Dan Cross wrote:

In article <10uoril$197kd$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/21/2026 5:36 PM, Keith Thompson wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/21/2026 2:06 PM, Dan Cross wrote:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

Is this commonly used, Kosher? Its from some really old code of mine.

Is *what* commonly used? What part of your 500+ lines of C code
are you asking about?

It appears to be two different *.h files. The first one appears
to depend on some macros that are defined in another header, but
it has no #include directives.

It's not worth my time to dig into it any further.

Say, this part:

[snip many lines of random typedefs and macros]

...you posted over a hundred lines of nothing but preprocessor
macros and typedefs, absent any kind of context.

Regardless, no, none of that is commonly used. Please don't
respond with some pointless question like, "don't people use
atomic operations?" or something vague and divorced from what
you are actually posting. For that matter, please don't post
any code that isn't accompanied by a specific, well-worded
question about that code.

Simply trying to abstract a cpu specific api into the main portable api. Macros and typedefs worked fine for me and the users. Quick and dirty
perhaps, but works.
_________
typedef ac_i686_intword_t ac_intword_t;
typedef ac_i686_uintword_t ac_uintword_t;

#define ac_atomic_cas_fence ac_i686_atomic_cas_fence
_________

The user uses the ac_atomic_cas_fence function. They do not need to
really care if its from an i686 or from a SPARC, a PPC, ect...


ac_i686_atomic_cas_fence has its impl in cpu specific ASM. Say:

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10uqfp2$1pdpu$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/22/2026 10:42 AM, Dan Cross wrote:

In article <10uoril$197kd$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/21/2026 5:36 PM, Keith Thompson wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/21/2026 2:06 PM, Dan Cross wrote:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

Is this commonly used, Kosher? Its from some really old code of mine. >>>>

Is *what* commonly used? What part of your 500+ lines of C code
are you asking about?

It appears to be two different *.h files. The first one appears
to depend on some macros that are defined in another header, but
it has no #include directives.

It's not worth my time to dig into it any further.

Say, this part:

[snip many lines of random typedefs and macros]

...you posted over a hundred lines of nothing but preprocessor
macros and typedefs, absent any kind of context.

Regardless, no, none of that is commonly used. Please don't
respond with some pointless question like, "don't people use
atomic operations?" or something vague and divorced from what
you are actually posting. For that matter, please don't post
any code that isn't accompanied by a specific, well-worded
question about that code.

Simply trying to abstract a cpu specific api into the main portable api. >Macros and typedefs worked fine for me and the users. Quick and dirty >perhaps, but works.
_________
typedef ac_i686_intword_t ac_intword_t;
typedef ac_i686_uintword_t ac_uintword_t;

#define ac_atomic_cas_fence ac_i686_atomic_cas_fence
_________

The user uses the ac_atomic_cas_fence function. They do not need to
really care if its from an i686 or from a SPARC, a PPC, ect...

ac_i686_atomic_cas_fence has its impl in cpu specific ASM. Say:

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

Ok, but that has nothing to do with why you are posting this now
and asking whether or not this code is "commonly used".

Are you asking about the technique of using `typedef` and
macros? Yes, those are used for writing portable code.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

There are a few people who sometimes post in comp.lang.c (and
perhaps other newsgroups) who are, IMO, never worth reading or
responding to. I'm sorry to say that Chris Thomasson is one of
them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <86lddahh5i.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

There are a few people who sometimes post in comp.lang.c (and
perhaps other newsgroups) who are, IMO, never worth reading or
responding to. I'm sorry to say that Chris Thomasson is one of
them.

I think you are correct. I apologize for adding to the noise.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/22/2026 2:03 PM, Dan Cross wrote:
[...]

Are you asking about the technique of using `typedef` and
macros?

Yeah. I was wondering if the macros are okay vs creating stub functions.

Yes, those are used for writing portable code.

They worked out pretty nice for me in that old lib I wrote.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/22/2026 9:41 PM, Tim Rentsch wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly? Did you have
some question about it? Was there some aspect of C you are
unsure of and you need some help?

There are a few people who sometimes post in comp.lang.c (and
perhaps other newsgroups) who are, IMO, never worth reading or
responding to. I'm sorry to say that Chris Thomasson is one of
them.

Shit happens. Fwiw, I have a long history on this group. Here is a fun
one where I posted my region allocator:

https://pastebin.com/raw/f37a23918

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

Actually, it's still in use today. It had a fun way to gain alignment
via offsetof.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/22/2026 2:03 PM, Dan Cross wrote:
[...]

Are you asking about the technique of using `typedef` and
macros?

Yeah. I was wondering if the macros are okay vs creating stub functions.

But you didn't say that. You just dumped hundreds of lines of code
and said *nothing* about it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/23/2026 8:55 PM, Keith Thompson wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/22/2026 2:03 PM, Dan Cross wrote:
[...]

Are you asking about the technique of using `typedef` and
macros?

Yeah. I was wondering if the macros are okay vs creating stub functions.

But you didn't say that. You just dumped hundreds of lines of code
and said *nothing* about it.

Yeah, I did, also sorry for the multiposts. My newsgroup server was down
today for a while, and god knows how many attempts I made. So shit man. Another one bites the dust!

https://youtu.be/OdurVND-DSs?list=RDOdurVND-DSs

;^)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 5/23/2026 11:38 PM, Chris M. Thomasson wrote:

On 5/22/2026 9:41 PM, Tim Rentsch wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <10unkj8$vaik$1@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

Fwiw, I found some of my old code:
[snip]

...And you felt compelled to post it, why exactly?  Did you have
some question about it?  Was there some aspect of C you are
unsure of and you need some help?

There are a few people who sometimes post in comp.lang.c (and
perhaps other newsgroups) who are, IMO, never worth reading or
responding to.  I'm sorry to say that Chris Thomasson is one of
them.

Shit happens. Fwiw, I have a long history on this group. Here is a fun
one where I posted my region allocator:

https://pastebin.com/raw/f37a23918

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

Actually, it's still in use today. It had a fun way to gain alignment
via offsetof.

Sorry for the multi post. Server down today. Make multiple attempts to
post. Shit happens! ;^o
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 24/05/2026 08:49, Chris M. Thomasson wrote:

On 5/23/2026 8:55 PM, Keith Thompson wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 5/22/2026 2:03 PM, Dan Cross wrote:
[...]

Are you asking about the technique of using `typedef` and
macros?

Yeah. I was wondering if the macros are okay vs creating stub functions.

What do you mean by "okay" ? The C language includes pre-processor
macros, so it is "okay" to use them. Are you asking if this is good
style? At first glance, I'd say it's some pretty horrible global name
space pollution, but I have no idea (or particular interest) in the context.

If you want to get useful advice, you'll have to do a lot better at
asking questions. It would be great to see some more topical and useful threads here.

But you didn't say that.  You just dumped hundreds of lines of code
and said *nothing* about it.

Yeah, I did, also sorry for the multiposts. My newsgroup server was down today for a while, and god knows how many attempts I made.

That's no problem. Apparently others had similar issues.


But can you /please/ cut out the stupid links?
--- Synchronet 3.22a-Linux NewsLink 1.2