A "forked" repository on GitHub always shows up as a forked repository. Usually when I see that at the top of a page, I think "oh, I should really go get the upstream changes, this is just some random guy's playground." That's not always the case, but most of the time it is. So I think it'd be better if the repository that Parallax is going tout as the "official" one not have "forked from ...." at the top
That's a good point to mention to Ken.
Given that, my suggestion would be to start with the master, released P1 gcc as the root, and then place ersmith's newer-version gcc as a derivative from there, and hopefully that can be made to operate with libraries and newer GCCs and become both a new p1.gcc, and from there, a basis for P2 work.
This seems like a bad idea. It loses all of the work Eric has done with his GCC6 repository. Better to start with that and try to figure out why Simple Libraries don't work. In fact, Simple Libraries don't work with the master branch of the Parallax propgcc repository either. Also, we don't even know if it is a bug in that GCC build. It could be a bug in the Simple Libraries that just happened not to matter in the release_1_0 GCC.
We probably want to wait for Parallax to hold their tools meeting before we do much more than discuss this. They may have opinions as to where to host the repository. My understanding is that this meeting will happen after we receive our P2-ES boards.
Ugh, it's a bit frustrating to wait for Parallax to hold a meeting. On September 30 Ken said that we would meet in the first week of November, which is a month ago. I think most people on the team have an FPGA board, and there's always spinsim. However, I guess we can wait a few more weeks fir O2-ES.
That's a good point to mention to Ken.
Given that, my suggestion would be to start with the master, released P1 gcc as the root, and then place ersmith's newer-version gcc as a derivative from there, and hopefully that can be made to operate with libraries and newer GCCs and become both a new p1.gcc, and from there, a basis for P2 work.
I agree with David Betz on this. Just start with Eric's code base. Why make more work for ourselves. Parallax hasn't even documented the incompatibilities between the later GCC code and the simple libraries. I'm sure if we know what the problems are we can easily fix them.
This seems like a bad idea. It loses all of the work Eric has done with his GCC6 repository. Better to start with that and try to figure out why Simple Libraries don't work. In fact, Simple Libraries don't work with the master branch of the Parallax propgcc repository either. Also, we don't even know if it is a bug in that GCC build. It could be a bug in the Simple Libraries that just happened not to matter in the release_1_0 GCC.
I must have been unclear, as that's exactly what I thought I was proposing, since Eric's work is derived from the earlier gcc.
I suggested using the current P1 gcc as root mainly for Parallax admin purposes, and so anyone arriving on that link, can see the upcoming new work.
This seems like a bad idea. It loses all of the work Eric has done with his GCC6 repository. Better to start with that and try to figure out why Simple Libraries don't work. In fact, Simple Libraries don't work with the master branch of the Parallax propgcc repository either. Also, we don't even know if it is a bug in that GCC build. It could be a bug in the Simple Libraries that just happened not to matter in the release_1_0 GCC.
I must have been unclear, as that's exactly what I thought I was proposing, since Eric's work is derived from the earlier gcc.
I suggested using the current P1 gcc as root mainly for Parallax admin purposes, and so anyone arriving on that link, can see the upcoming new work.
Sorry, I thought you meant to use the default branch of the Parallax propgcc repository. That is still using GCC4.
We probably want to wait for Parallax to hold their tools meeting before we do much more than discuss this. They may have opinions as to where to host the repository. My understanding is that this meeting will happen after we receive our P2-ES boards.
Ugh, it's a bit frustrating to wait for Parallax to hold a meeting. On September 30 Ken said that we would meet in the first week of November, which is a month ago. I think most people on the team have an FPGA board, and there's always spinsim. However, I guess we can wait a few more weeks fir O2-ES.
I think the problem is that Parallax is busy getting P2-ES ready to ship. I don't think they currently have time to meet with us.
We can clone it and check it into the Parallax GitHub account if they will allow that. Or maybe we can ask them to create a parallax-dev GitHub account to keep the stuff under development separate from the release Parallax products.
If Eric is willing, we can actually transfer ownership to the Parallax org. This will keep history for bugs and issues that were opened (and closed).
I don't see any reason to transfer ownership -- the beauty of github is that it's easy to fork projects, and you certainly don't need my permission to do that (although of course you have it!).
A "forked" repository on GitHub always shows up as a forked repository. Usually when I see that at the top of a page, I think "oh, I should really go get the upstream changes, this is just some random guy's playground." That's not always the case, but most of the time it is. So I think it'd be better if the repository that Parallax is going tout as the "official" one not have "forked from ...." at the top
Other than that, I agree that forking would be sufficient. My original post about this revolved around the issue tracker and keeping its history.... but the repository in question only has a single issue with a single comment.
If you manually fork it, i.e. have a local clone of it, create a new empty repository on Github, add the new empty repository as a remote of your local copy, and then push your local copy to your new Github repository, it won't know that it's a fork.
We can clone it and check it into the Parallax GitHub account if they will allow that. Or maybe we can ask them to create a parallax-dev GitHub account to keep the stuff under development separate from the release Parallax products.
If Eric is willing, we can actually transfer ownership to the Parallax org. This will keep history for bugs and issues that were opened (and closed).
I don't see any reason to transfer ownership -- the beauty of github is that it's easy to fork projects, and you certainly don't need my permission to do that (although of course you have it!).
A "forked" repository on GitHub always shows up as a forked repository. Usually when I see that at the top of a page, I think "oh, I should really go get the upstream changes, this is just some random guy's playground." That's not always the case, but most of the time it is. So I think it'd be better if the repository that Parallax is going tout as the "official" one not have "forked from ...." at the top
Other than that, I agree that forking would be sufficient. My original post about this revolved around the issue tracker and keeping its history.... but the repository in question only has a single issue with a single comment.
If you manually fork it, i.e. have a local clone of it, create a new empty repository on Github, add the new empty repository as a remote of your local copy, and then push your local copy to your new Github repository, it won't know that it's a fork.
Indeed all problems solved then. So now we just need someone with power on https://github.com/parallaxinc/ to create a new repo and grant access to contributors... that probably means we're stuck waiting for Ken or Andy unless we want to start development in someone else's GitHub account and move it to Parallax's at a later date.
We still have to decide how to organize all of the pieces of this project. When you talk about creating a new repo, do you mean just for gcc or do you mean a container project like propgcc or propeller-gcc that includes all of the pieces like gcc, binutils, the libraries, etc?
We still have to decide how to organize all of the pieces of this project. When you talk about creating a new repo, do you mean just for gcc or do you mean a container project like propgcc or propeller-gcc that includes all of the pieces like gcc, binutils, the libraries, etc?
Without having done development on PropGCC, I don't want to give an opinion on that. To the previous PropGCC devs: what did you like more?
Hey guys,
I suggest you enlist a newbie to gcc party, markmpx.
Mark has more than 30 years of C and created his own ISP company back in the 90's. He's lurking here and itching to get his feet wet on P2.
Welcome, Mark! Is that 30 years of C programming or 30 years of experience with implementing C compilers? Either way, I suspect you'll be able to make a big contribution.
Hey guys,
I suggest you enlist a newbie to gcc party, markmpx.
Mark has more than 30 years of C and created his own ISP company back in the 90's. He's lurking here and itching to get his feet wet on P2.
Welcome, Mark! Is that 30 years of C programming or 30 years of experience with implementing C compilers? Either way, I suspect you'll be able to make a big contribution.
I think what David meant to say was "Welcome, @markmpx!"
Hey guys,
I suggest you enlist a newbie to gcc party, markmpx.
Mark has more than 30 years of C and created his own ISP company back in the 90's. He's lurking here and itching to get his feet wet on P2.
Welcome, Mark! Is that 30 years of C programming or 30 years of experience with implementing C compilers? Either way, I suspect you'll be able to make a big contribution.
I think what David meant to say was "Welcome, @markmpx!"
Well, I guess I made the assumption that "markmpx" referred to a person named "Mark". Maybe that was an unwarranted assumption?
Hey guys,
I suggest you enlist a newbie to gcc party, markmpx.
Mark has more than 30 years of C and created his own ISP company back in the 90's. He's lurking here and itching to get his feet wet on P2.
Welcome, Mark! Is that 30 years of C programming or 30 years of experience with implementing C compilers? Either way, I suspect you'll be able to make a big contribution.
I think what David meant to say was "Welcome, @markmpx!"
Well, I guess I made the assumption that "markmpx" referred to a person named "Mark". Maybe that was an unwarranted assumption?
Seems a valid assumption. I just thought he might want to be tagged and included in the conversation.
come on @"David Betz" just hit the @ and type the first two letters of the name. Sadly it seems that all of us are old. I mean we all got old by waiting for the P2.
I was young AND beautiful when the P2 tread started. now I am just AND.
Hey guys,
I suggest you enlist a newbie to gcc party, markmpx.
Mark has more than 30 years of C and created his own ISP company back in the 90's. He's lurking here and itching to get his feet wet on P2.
Welcome, Mark! Is that 30 years of C programming or 30 years of experience with implementing C compilers? Either way, I suspect you'll be able to make a big contribution.
I think what David meant to say was "Welcome, @markmpx!"
Well, I guess I made the assumption that "markmpx" referred to a person named "Mark". Maybe that was an unwarranted assumption?
Seems a valid assumption. I just thought he might want to be tagged and included in the conversation.
Hi all,
Cluso99 is correct, i have been lurking on these forums for some time, and thanks for the welcome !
To answer your questions, i have 30+ years of C experience, but not a lot of experience with implementing
C compilers. I have modified the back end of the gcc C compiler (and also gas) many years ago. I have
written linkers/loaders to run as the final stage of the gcc toolchain to load into various embedded boards that i used.
I have a mountain of experience with assembler (S360/390 thru to many modern cpus).
I do have a large amount of experience with writing/modifying compilers, but not C compilers.
Most of my compiler experience is with the Wirth type compilers. (eg: Pascal, Modula, Oberon family)
Long term i need a good C compiler on the Prop2, and am happy to work with others to achieve this.
Short term, i need experience on the Prop2, i never used the P1. To write a compiler backend requires
an intimate knowledge of the instruction set/architecture. I will get this experience with Prop2 by writing
a new back end for the latest version of the Oberon 07 Compiler to target the Prop2.
I plan to make all the source code available on github under a MIT license. The Oberon 07 Prop 2
compiler and tools will be written in C such that it will run on Windows, Linux, MacOS, BSD,Dos etc.
I wont post more in this thread about Oberon,i will make a new thread on the Forum eventually, or you can start an Oberon thread and i will answer any questions in that thread.
I am impressed by some of the posted assembly code that the fastspin/C compiler can produce ! Now if
that was combined with all the optimizations gcc can produce ...
Comments
I agree with David Betz on this. Just start with Eric's code base. Why make more work for ourselves. Parallax hasn't even documented the incompatibilities between the later GCC code and the simple libraries. I'm sure if we know what the problems are we can easily fix them.
It only adds that if you use github's specific functionality. If you do it by hand, it doesn't.
Github has the concept of ownership, git doesn't.
See https://github.com/redvers/SimpleIDE
Retains all history, no mention of fork.
(Note - I only pulled one branch for the demo)
I must have been unclear, as that's exactly what I thought I was proposing, since Eric's work is derived from the earlier gcc.
I suggested using the current P1 gcc as root mainly for Parallax admin purposes, and so anyone arriving on that link, can see the upcoming new work.
If you manually fork it, i.e. have a local clone of it, create a new empty repository on Github, add the new empty repository as a remote of your local copy, and then push your local copy to your new Github repository, it won't know that it's a fork.
Indeed
Without having done development on PropGCC, I don't want to give an opinion on that. To the previous PropGCC devs: what did you like more?
I suggest you enlist a newbie to gcc party, markmpx.
Mark has more than 30 years of C and created his own ISP company back in the 90's. He's lurking here and itching to get his feet wet on P2.
I think what David meant to say was "Welcome, @markmpx!"
Seems a valid assumption. I just thought he might want to be tagged and included in the conversation.
I was young AND beautiful when the P2 tread started. now I am just AND.
Enjoy!
Mike
They remind me every birthday. I swiftly forget again
I'm now in my 30s and have four kids. *lol*
Time flies.
I'm just glad to still see old faces still hanging around here after all these years. : ]
Here is a list I found online of the standard libraries:
https://en.wikipedia.org/wiki/C_standard_library
I'm guessing it would be a good idea to rewrite these as highly optimized P2 ASM?
Hi all,
Cluso99 is correct, i have been lurking on these forums for some time, and thanks for the welcome !
To answer your questions, i have 30+ years of C experience, but not a lot of experience with implementing
C compilers. I have modified the back end of the gcc C compiler (and also gas) many years ago. I have
written linkers/loaders to run as the final stage of the gcc toolchain to load into various embedded boards that i used.
I have a mountain of experience with assembler (S360/390 thru to many modern cpus).
I do have a large amount of experience with writing/modifying compilers, but not C compilers.
Most of my compiler experience is with the Wirth type compilers. (eg: Pascal, Modula, Oberon family)
Long term i need a good C compiler on the Prop2, and am happy to work with others to achieve this.
Short term, i need experience on the Prop2, i never used the P1. To write a compiler backend requires
an intimate knowledge of the instruction set/architecture. I will get this experience with Prop2 by writing
a new back end for the latest version of the Oberon 07 Compiler to target the Prop2.
I plan to make all the source code available on github under a MIT license. The Oberon 07 Prop 2
compiler and tools will be written in C such that it will run on Windows, Linux, MacOS, BSD,Dos etc.
I wont post more in this thread about Oberon,i will make a new thread on the Forum eventually, or you can start an Oberon thread and i will answer any questions in that thread.
I am impressed by some of the posted assembly code that the fastspin/C compiler can produce ! Now if
that was combined with all the optimizations gcc can produce ...
And yes, my real name is actually mark.