public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Request for Direction.
  2023-12-15 19:43 Request for Direction David H. Lynch Jr.
@ 2023-12-15  1:50 ` James K. Lowden
  2023-12-16 22:41   ` David H. Lynch Jr.
  0 siblings, 1 reply; 7+ messages in thread
From: James K. Lowden @ 2023-12-15  1:50 UTC (permalink / raw)
  To: David H. Lynch Jr. via Gcc

On Fri, 15 Dec 2023 14:43:22 -0500
"David H. Lynch Jr. via Gcc" <gcc@gcc.gnu.org> wrote:

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

Hi David, 

My colleague Bob Dubner and I have been extending GCC every day for
the last two years.  I wonder if we might be of some use to you.  

I only faintly hope our project can benefit from your work. We're
adding a Cobol front end to GCC.  Cobol has built-in sort functions,
both on disk and in memory, and a rich data-description language.
There is more potential there than might seem at first blush, and I
would welcome the opportunity to explain in detail if you're
interested.  

If your objective is simply to extend C to support content addressable
memory, then we might still be of some help.  I don't know anything,
really, about the C front-end, but Bob has experience getting
Generic to generate code.  He might be able to answer some of your
questions, if nothing else.

Let me know what you think.  

Kind regards, 

--jkl


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Request for Direction.
@ 2023-12-15 19:43 David H. Lynch Jr.
  2023-12-15  1:50 ` James K. Lowden
  0 siblings, 1 reply; 7+ messages in thread
From: David H. Lynch Jr. @ 2023-12-15 19:43 UTC (permalink / raw)
  To: gcc

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. 



  








 





  

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Request for Direction.
  2023-12-15  1:50 ` James K. Lowden
@ 2023-12-16 22:41   ` David H. Lynch Jr.
  2023-12-16 22:51     ` Jonathan Wakely
  0 siblings, 1 reply; 7+ messages in thread
From: David H. Lynch Jr. @ 2023-12-16 22:41 UTC (permalink / raw)
  To: James K. Lowden, gcc

On Thu, 2023-12-14 at 20:50 -0500, James K. Lowden wrote:
> On Fri, 15 Dec 2023 14:43:22 -0500
> "David H. Lynch Jr. via Gcc" <gcc@gcc.gnu.org> wrote:
> 
> > Right now I am just focused on some means to deliver support. 
> 
> Hi David, 
> 
> My colleague Bob Dubner and I have been extending GCC every day for
> the last two years.  I wonder if we might be of some use to you.  
> 
> I only faintly hope our project can benefit from your work. We're
> adding a Cobol front end to GCC.  Cobol has built-in sort functions,
> both on disk and in memory, and a rich data-description language.

I have not thought regarding COBOL.  I have not used COBOL since the
early 80's.  
Regardless, The work we are doing likely has a high synergy with COBOL.
The core issue would be that COBOL is not a high profile target. 

The current work is focused on delivering a demonstration project with
enough sex appeal to attract the resources to more fully develop our
work. 

This project started with a major memory manufacturer about 5 years
ago.  Dr. Trout and I developed it there. We secured the rights to our
work when we left.  We have been working on it on our own since. 

The original "target" was Sort-in-memory - which we demonstrated on
FPGA's several years ago. We were very close to having DRAM fabricated
when we left. We have subsequently expanded our idea to incorporate
numerous memory access/addressing options. 

One of the target applications is handling of sparse arrays, and
directly accessing the cells using existing sparse array notation. 


That is particularly applicable to AI. 

We are in the process of trying to take a standard AI reference
application - recognizing handwritten numbers and being able to
demonstrate everything - from the application through the compiler to
the memory access.  Doing a complete end to end problem helps get the
mundane issues that have not been addressed completed. 

The AI app we are using is in C/C++ so that is our focus. 

Our long term objective is the hardware itself - currently our target
is DRAM, but our work is applicable to all forms of storage - from DDR
through to Hard disks. 

Frankly there are applications we have not even thought of. 

Technically this is Processor-In-Memory - which others such as Samsung
are doing.  But our approach is quite different, we are dual purposing
the addressing logic and making use of a 4 bit processor to dynamically
alter the way memory is addressed/accessed. 

Right now MY priority is adding support to a c/c++ compiler for our
memory. I can  do this myself, But I have not worked on compilers for
30 years and I have not ever worked on GCC. 

I am looking for any help I can get - pointers as to where to start
with GCC, docs or howto's through to someone that wishes to participate
in the project.  There is a potential for compensation - we are seeking
a grant, though our long term goals are partnership with a Memory
vendor.


We have worked out a syntax with out preprocessor, but we are not
committed to that. 

There are some aspects that we are not sure how map into a programming
language.  Regardless the goal is not to get everything right it is to
prove the value of the concept. 

Currently AI is where all the focus is - which is why we are doing an
end to end AI application. Everything at the MEMSYS conference where we
presented our work was either directly or indirectly about AI. 

Absolutely COBOL with Sort in Memory would be wonderful, but it is not
likely to attract interest int eh addressing technology that is out key
idea. 

Regardless, anyone interested can contact me either on this list or
directly via email.  I am looking for help and guidance and I do not
have  a preconception for what that might mean. 

 














> There is more potential there than might seem at first blush, and I
> would welcome the opportunity to explain in detail if you're
> interested.  
> 
> If your objective is simply to extend C to support content
> addressable
> memory, then we might still be of some help.  I don't know anything,
> really, about the C front-end, but Bob has experience getting
> Generic to generate code.  He might be able to answer some of your
> questions, if nothing else.
> 
> Let me know what you think.  
> 
> Kind regards, 
> 
> --jkl
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Request for Direction.
  2023-12-16 22:41   ` David H. Lynch Jr.
@ 2023-12-16 22:51     ` Jonathan Wakely
  2023-12-18  7:59       ` Richard Biener
  0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Wakely @ 2023-12-16 22:51 UTC (permalink / raw)
  To: david.lynch; +Cc: James K. Lowden, gcc

On Sat, 16 Dec 2023 at 22:41, David H. Lynch Jr. wrote:
> I am looking for any help I can get - pointers as to where to start
> with GCC, docs or howto's through to someone that wishes to participate
> in the project.  There is a potential for compensation - we are seeking
> a grant, though our long term goals are partnership with a Memory
> vendor.

I would start with https://gcc.gnu.org/wiki/GettingStarted
and the docs it links to at https://gcc-newbies-guide.readthedocs.io/en/latest/

This list is the place to ask if you get stuck, or the #gcc channel on
the OFTC IRC network.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Request for Direction.
  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.
  0 siblings, 2 replies; 7+ messages in thread
From: Richard Biener @ 2023-12-18  7:59 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: david.lynch, James K. Lowden, gcc

On Sat, Dec 16, 2023 at 11:53 PM Jonathan Wakely via Gcc
<gcc@gcc.gnu.org> wrote:
>
> On Sat, 16 Dec 2023 at 22:41, David H. Lynch Jr. wrote:
> > I am looking for any help I can get - pointers as to where to start
> > with GCC, docs or howto's through to someone that wishes to participate
> > in the project.  There is a potential for compensation - we are seeking
> > a grant, though our long term goals are partnership with a Memory
> > vendor.
>
> I would start with https://gcc.gnu.org/wiki/GettingStarted
> and the docs it links to at https://gcc-newbies-guide.readthedocs.io/en/latest/

You might also want to look at named address spaces, though they
are tracked as qualifiers.  Generally annotations to declarations are
easiest as custom attributes, though I would guess you need to
be able to annotate pointer (types) as well, thus my hint with the
address-spaces.  I guess handling all Content addressable variables
as being in a single special address space isn't enough of information
to address them.

Richard.

> This list is the place to ask if you get stuck, or the #gcc channel on
> the OFTC IRC network.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Request for Direction.
  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.
  1 sibling, 0 replies; 7+ messages in thread
From: David H. Lynch Jr. @ 2023-12-19 21:58 UTC (permalink / raw)
  To: Richard Biener, Jonathan Wakely; +Cc: James K. Lowden, gcc

Thx,

I appreciate the direction. 

We used a special tag in the preprocessor that we did. But there is no
requirement of any specific means or syntax. 

we have been calling content addressable variables "sarts".

So the first thing we must do is take almost any existing variable and
identify it as a sart - that would be an attibute. 

But it must also belong to a specific group/block/.... Name spaces
could deal with this, but depending on the problem there could be one
namespace for all CA variables or many different namespaces. 


Basically the variable must be identified as content addressable, and
it must be tagged as utilizing a specific address translation
mechanism. 

The next issue is that when the variable is used any type of bounds
checking must be disabled because the "bounds" of a sart or content
addressible variable are not easily known by the compiler. 

Next the code generated for get/put will be different. 













On Mon, 2023-12-18 at 08:59 +0100, Richard Biener via Gcc wrote:
> On Sat, Dec 16, 2023 at 11:53 PM Jonathan Wakely via Gcc
> <gcc@gcc.gnu.org> wrote:
> > 
> > On Sat, 16 Dec 2023 at 22:41, David H. Lynch Jr. wrote:
> > > I am looking for any help I can get - pointers as to where to
> > > start
> > > with GCC, docs or howto's through to someone that wishes to
> > > participate
> > > in the project.  There is a potential for compensation - we are
> > > seeking
> > > a grant, though our long term goals are partnership with a Memory
> > > vendor.
> > 
> > I would start with https://gcc.gnu.org/wiki/GettingStarted
> > and the docs it links to at
> > https://gcc-newbies-guide.readthedocs.io/en/latest/
> 
> You might also want to look at named address spaces, though they
> are tracked as qualifiers.  Generally annotations to declarations are
> easiest as custom attributes, though I would guess you need to
> be able to annotate pointer (types) as well, thus my hint with the
> address-spaces.  I guess handling all Content addressable variables
> as being in a single special address space isn't enough of
> information
> to address them.
> 
> Richard.
> 
> > This list is the place to ask if you get stuck, or the #gcc channel
> > on
> > the OFTC IRC network.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Request for Direction.
  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.
  1 sibling, 0 replies; 7+ messages in thread
From: David H. Lynch Jr. @ 2023-12-19 22:02 UTC (permalink / raw)
  To: Richard Biener, Jonathan Wakely; +Cc: James K. Lowden, gcc

For now I just need to be able to impliment something relatively simply
so that we can write take some existing applications - such as AI, or
sparse arrays or  .... and demonstrate/test end to end our concept. 

If it is successful and various others think there is a better syntax,
or means of implimenting that is a future problem. 



On Mon, 2023-12-18 at 08:59 +0100, Richard Biener wrote:
> On Sat, Dec 16, 2023 at 11:53 PM Jonathan Wakely via Gcc
> <gcc@gcc.gnu.org> wrote:
> > 
> > On Sat, 16 Dec 2023 at 22:41, David H. Lynch Jr. wrote:
> > > I am looking for any help I can get - pointers as to where to
> > > start
> > > with GCC, docs or howto's through to someone that wishes to
> > > participate
> > > in the project.  There is a potential for compensation - we are
> > > seeking
> > > a grant, though our long term goals are partnership with a Memory
> > > vendor.
> > 
> > I would start with https://gcc.gnu.org/wiki/GettingStarted
> > and the docs it links to at
> > https://gcc-newbies-guide.readthedocs.io/en/latest/
> 
> You might also want to look at named address spaces, though they
> are tracked as qualifiers.  Generally annotations to declarations are
> easiest as custom attributes, though I would guess you need to
> be able to annotate pointer (types) as well, thus my hint with the
> address-spaces.  I guess handling all Content addressable variables
> as being in a single special address space isn't enough of
> information
> to address them.
> 
> Richard.
> 
> > This list is the place to ask if you get stuck, or the #gcc channel
> > on
> > the OFTC IRC network.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-12-19 22:02 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-15 19:43 Request for Direction David H. Lynch Jr.
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.

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).