public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "David H. Lynch Jr." <dhlynch2@gmail.com>
To: gcc@gcc.gnu.org
Subject: Request for Direction.
Date: Fri, 15 Dec 2023 14:43:22 -0500	[thread overview]
Message-ID: <f384799574df7eba0132ddebecf377329542974c.camel@dlasys.net> (raw)

I am part of a project developing content addressable memory.  I am the
2nd author for a paper on this presented at MEMSYS 2023, and with
additions likely to be accepted by ACM shortly. 
https://www.memsys.io/wp-content/uploads/2023/09/10.pdf

My role is to develop software to demonstrate the benefits of the
hardware/memory. A part of that is implimenting language extensions to
provide native support for content addressible memory.  
And then to modify some applications to utilize those extensions and
demonstrate the value. 

We have already developed a C/C++ preprocessor, that is mostly
functional,  but are looking to move to altering some actual compilers.

At this time this work is purely proof of the value proposition to
content addressible memory. Presuming that our work proves valuable, 
that will provide an impetus for further works. 

Right now I am just focused on some means to deliver support. 

So I am looking for direction regarding how to easily extend gcc to
provide support for content addressible memory.  

Basically I need to be able to tag variables as Content addressable,
rather than normally addressed, and then change code generation for CA
variables such that they reference memory by key rather than address. 

Is there a guide anywhere to developing language extensions for GCC
and/or making changes to code generation ?

I am a competent embedded software developer, with some ancient
experience with compilers, but starting from scratch with GCC. 
Pointers would be appreicated.  Help would be appreciated. While I am
leading this part of the project, there is some funding available for
assistance. 

Some recent languages have some form of content based addressing, but
this is implimented by the CPU.  We have altered the address logic of
memory to alter the way an "address" is handled ushc that it can
function as a key rather than a traditional linear address. 

We have demonstrated Sort in Memory with relatively simple changes to
memory addressing logic, and we have extended the addressing
capabilities to things like sparse array notation which has
applications to AI. 

We are not looking to feed anything into the GCC distribution. 
But the software  will be open source. 



  








 





  

             reply	other threads:[~2023-12-15 19:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-15 19:43 David H. Lynch Jr. [this message]
2023-12-15  1:50 ` James K. Lowden
2023-12-16 22:41   ` David H. Lynch Jr.
2023-12-16 22:51     ` Jonathan Wakely
2023-12-18  7:59       ` Richard Biener
2023-12-19 21:58         ` David H. Lynch Jr.
2023-12-19 22:02         ` David H. Lynch Jr.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f384799574df7eba0132ddebecf377329542974c.camel@dlasys.net \
    --to=dhlynch2@gmail.com \
    --cc=davidlynch@dlasys.net \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).