Menu
▾
▴
anyc-devel
|
From: Daniel W. <dan...@ro...> - 2001-07-16 00:07:51
|
I guess now that this listserver is set up we should move discussion he= re.=20 I have been looking at the Atmel AVR series microcontrollers, especiall= y=20 now that Digikey is carrying them (page 194-195 of the current catalog). = I=20 would still like to make a compiler that would work with PIC series=20 microcontrollers, but the page and bank issues seemed extremely difficult= =20 when I was seriously working on the compiler. The AVR series seem to hav= e=20 the benefits of the PIC products, but without the compiler-unfriendly ban= k=20 and page issues. The one drawback to the AVR method is that it takes 2=20 instructions to do some of the jump instructions, but this seems like a s= mall=20 price to pay. |
|
From: Patrick E. <pa...@pa...> - 2001-07-16 03:13:55
|
On Sunday 15 July 2001 11:24, you wrote:
> I have been looking at the Atmel AVR series microcontrollers,
> especially now that Digikey is carrying them (page 194-195 of the
> current catalog). I would still like to make a compiler that would
> work with PIC series microcontrollers, but the page and bank issues
> seemed extremely difficult when I was seriously working on the
> compiler. The AVR series seem to have the benefits of the PIC
> products, but without the compiler-unfriendly bank and page issues.
> The one drawback to the AVR method is that it takes 2 instructions
> to do some of the jump instructions, but this seems like a small
> price to pay.
What are the price differences like between the AVRs and the PICs?
One of the things I like about the PIC is that they're pretty cheap
for the feature set they offer. I can't speak for other
microcontrollers though, since I haven't really looked that much.
I'm sure the page and bank issues can be worked out satisfactorily
through some creative design and tradeoffs. They're always somewhat
on my mind as I've been working. I'm sure solutions will eventually
present themselves to any problems we may encounter.
I've been thinking about somehow offering a virtual pseudo-linear
address space. This is a rather half baked idea, but perhaps it
would be possible to take the space requirements for various
variables, and organize them into chunks of memory within the same
page. That way, array and other multi-byte variable accesses could
be done without switching banks. This wouldn't lend itself
particularly well to working within a traditional stack though.
However, perhaps emulating the traditional stack isn't the best way
to work with the PICs.
Instead of implementing a basic system on a stack machine, perhaps
there could be a more general memory management system that deals
with either the specifics of the PICs or works with more stack based
systems like the AVR. This is going to require a more thought. Do
you have any ideas in the area of memory management? Do you see any
fatal flaws in the half-baked ideas here?
Thanks.
Patrick Earl
|
|
From: Daniel W. <dan...@ro...> - 2001-07-16 06:28:18
|
> What are the price differences like between the AVRs and the PICs? > One of the things I like about the PIC is that they're pretty cheap > for the feature set they offer. I can't speak for other > microcontrollers though, since I haven't really looked that much. I was looking at the comparison between the PIC 16F877 and the AVR AT90S8= 535.=20 They are both about $10 and have 8k flash memory. Other major factors: =09PIC=09AVR RAM=09368=09512 EEPROM=09265=09512 IO=0933=0930 A/D=098 chan.=098 chan. (both 10-bit resolution) SPI=09yes=09yes UART=09yes=09yes I didn't look up everything, but it appears to me that Atmel is trying = to=20 match the PIC feature for feature. =20 Another really nice thing about the AVR series is that there are 32 gen= eral=20 purpose registers, and you can operate on any two for many of the operati= ons.=20 For example, you could say: ADC #$3,#$15 to add register 3 to register $15 and put the result in register 3. > I'm sure the page and bank issues can be worked out satisfactorily > through some creative design and tradeoffs. They're always somewhat > on my mind as I've been working. I'm sure solutions will eventually > present themselves to any problems we may encounter. > > I've been thinking about somehow offering a virtual pseudo-linear > address space. This is a rather half baked idea, but perhaps it > would be possible to take the space requirements for various > variables, and organize them into chunks of memory within the same > page. That way, array and other multi-byte variable accesses could > be done without switching banks. This wouldn't lend itself > particularly well to working within a traditional stack though. > However, perhaps emulating the traditional stack isn't the best way > to work with the PICs. Hmm... I think expression parsing might be tougher this way. Also, wh= at=20 if you wanted one big array? Considering how small the RAM is on these=20 things, if they are used for one task, it seems likely this would happen.= =20 The solutions I considered before to solve this issue increased code size= a=20 good bit. =20 > Instead of implementing a basic system on a stack machine, perhaps > there could be a more general memory management system that deals > with either the specifics of the PICs or works with more stack based > systems like the AVR. This is going to require a more thought. Do > you have any ideas in the area of memory management? Do you see any > fatal flaws in the half-baked ideas here? I doubt if I am sophisticated enough to come up with a system better th= an=20 the traditional stack. Computer science isn't my field, I just picked th= is=20 stuff up as I went. I have "the dragon book", but I haven't read very fa= r=20 yet. Mostly a shortage of time. |
|
From: Daniel W. <dan...@ro...> - 2001-07-28 09:56:20
|
I have been looking over the code and thinking about this project, and=20 something occurred to me: The code is probably over 90% finished, and considering that, I would lik= e to=20 have sole copyright of the code. There are a couple of reasons for this: 1. Since I have written most of the code already, I have a lot to lose, a= nd=20 not much to gain by incorporating code that I don't hold copyright of. 2. If I ever wanted to dual-lisence the code, it would be incredibly=20 complicated if I wasn't the only copyright holder. Other lisences, such = as=20 the one used by Qt, would be interesting if anyone was ever interested in= =20 using AnyC in a commercial software product. This is not to say will change to a non-GPL license for the project. T= he=20 main project will stay GPL, but if it ever looked promising to extend int= o a=20 commercial product, I would like to have the possibility. =20 The effect of this is that I would like to be the one to make any major= =20 code additions or changes to the project. I think the stuff you (Patrick= )=20 have done so far would fall under the category of "minor" changes, which=20 would mean I still hold copyright on all the code on sourceforge. Please= let=20 me know if you feel this is wrong! By the way, I am working on the documentation, and will update CVS and = send=20 you a message here when I have a reasonable amount done. I went through = most=20 of the code this week, and have a very good feel for how the system works= =2E =20 It is fairly close to being finished code-wise, but will need a lot of=20 testing and documentation after the last bit is finished. |
|
From: Patrick E. <pa...@pa...> - 2001-08-08 18:39:58
|
On Saturday 28 July 2001 02:59, you wrote:
> I have been looking over the code and thinking about this project,
> and something occurred to me:
> The code is probably over 90% finished, and considering that, I
> would like to have sole copyright of the code. There are a couple
> of reasons for this:
>
> 1. Since I have written most of the code already, I have a lot to
> lose, and not much to gain by incorporating code that I don't hold
> copyright of.
>
> 2. If I ever wanted to dual-lisence the code, it would be
> incredibly complicated if I wasn't the only copyright holder.
> Other lisences, such as the one used by Qt, would be interesting if
> anyone was ever interested in using AnyC in a commercial software
> product.
>
> This is not to say will change to a non-GPL license for the
> project. The main project will stay GPL, but if it ever looked
> promising to extend into a commercial product, I would like to have
> the possibility.
> The effect of this is that I would like to be the one to make any
> major code additions or changes to the project. I think the stuff
> you (Patrick) have done so far would fall under the category of
> "minor" changes, which would mean I still hold copyright on all the
> code on sourceforge. Please let me know if you feel this is wrong!
I can see your point with these issues. I do not have any problem
with them. I'll go so far as to say that for any code I have
committed, or will commit to the CVS, I assign copyright ownership to
you. Because of this, I may choose to leave what I consider to be
interesting changes outside of the CVS. They would be incorporated
as patches or as a forked version, as allowed by the GPL. That said,
I'm not anticipating anything interesting very soon, so I imagine
that won't even be an issue for now. If I do make some sort of
interesting change, perhaps we can work something out, where I
receive recognition for it, and you get copyright ownership on it.
Anyways, we'll have to jump over those hurdles when and if we come to
them. For now, it's all yours, and full speed ahead.
> By the way, I am working on the documentation, and will update
> CVS and send you a message here when I have a reasonable amount
> done. I went through most of the code this week, and have a very
> good feel for how the system works. It is fairly close to being
> finished code-wise, but will need a lot of testing and
> documentation after the last bit is finished.
I haven't heard from you since this letter, so I assume you're not
finished. I had almost no time on my trip to do anything
interesting, so I didn't have time to review the AnyC source as I had
wanted. Is some of the documentation you're writing an architectural
overview of the project? It would be rather helpful for me to see
the big picture of what's going on in the compiler.
Look forward to hearing from you. Take care.
Patrick Earl
|
|
From: Daniel W. <dan...@ro...> - 2001-08-08 19:35:54
|
> I can see your point with these issues. I do not have any problem > with them. I'll go so far as to say that for any code I have > committed, or will commit to the CVS, I assign copyright ownership to > you. Because of this, I may choose to leave what I consider to be > interesting changes outside of the CVS. They would be incorporated > as patches or as a forked version, as allowed by the GPL. That said, > I'm not anticipating anything interesting very soon, so I imagine > that won't even be an issue for now. If I do make some sort of > interesting change, perhaps we can work something out, where I > receive recognition for it, and you get copyright ownership on it. > Anyways, we'll have to jump over those hurdles when and if we come to > them. For now, it's all yours, and full speed ahead. Great! Some people get pretty annoyed at anything that's not "pure" GP= L. =20 I'm guessing you probably understand the intricacies of the license. The= =20 only difference this would make is that I could take the GPL version and = make=20 an "extended" version that was not GPL, or even dual license the current=20 version. Obviously anything released under the GPL can't be "taken back"= =2E =20 Realistically, the scenario I was thinking of was if a company wanted t= o=20 incorporate this program into a commercial compiler. As much as it is wr= ong,=20 many buisiness people believe that proprietary and expensive code is alwa= ys=20 higher quality. =20 As you say, though, this is all in the future. I just wanted to clear = it=20 up now just in case. =20 > I haven't heard from you since this letter, so I assume you're not > finished. I had almost no time on my trip to do anything > interesting, so I didn't have time to review the AnyC source as I had > wanted. Is some of the documentation you're writing an architectural > overview of the project? It would be rather helpful for me to see > the big picture of what's going on in the compiler. I haven't worked on the docs since then, but I will soon. I am trying = to=20 write "big-picture" documentation first. It is harder than I thought it=20 would be. It will probably be much easier on you if you wait for at leas= t=20 some of the new docs I am writing before you try to tackle the source. I= =20 think the methods I am using are logical, but they probably aren't just l= ike=20 other compilers, since I have never worked on compilers before this, and = I'm=20 not a computer science student. |
|
From: Daniel W. <dan...@ro...> - 2001-08-16 00:26:01
|
Ok, I have put a new version of doc/anyc.lyx in CVS. Also, I added=20 anyc.pdf, anyc.ps, and anyc.html if you prefer a different format! Chapt= ers=20 5 and 6 are the only parts that are coherent (I hope) right now. The=20 rest of it is what I pulled out of the old documentation, and is not good= at=20 all (or very important either). |
|
From: Patrick E. <pa...@pa...> - 2001-08-16 05:29:45
|
On Wednesday 15 August 2001 17:30, you wrote:
> Ok, I have put a new version of doc/anyc.lyx in CVS. Also, I
> added anyc.pdf, anyc.ps, and anyc.html if you prefer a different
> format! Chapters 5 and 6 are the only parts that are coherent (I
> hope) right now. The rest of it is what I pulled out of the old
> documentation, and is not good at all (or very important either).
I see all of the files except the .lyx file. Are you sure you put it
in there?
I have some questions about the document too.
Are static local variables also included in the fixed global memory?
In 6.1.3 are the MATHx variables the size of the largest basic type
(ie. not arrays/structures)?
Are function return addresses really placed on the stack? What about
function return values?
Thanks :)
Patrick Earl - pa...@pa...
|
|
From: Daniel W. <dan...@ro...> - 2001-08-16 07:31:41
|
> I see all of the files except the .lyx file. Are you sure you put it > in there? Oops. I thought I did the cvs add for that file a long time ago, but I= =20 didn't. It's there now. > I have some questions about the document too. > > Are static local variables also included in the fixed global memory? I think so, although I'm not sure if they are in there yet. Is that th= e=20 way it is normally done? > In 6.1.3 are the MATHx variables the size of the largest basic type > (ie. not arrays/structures)? Yes. I'm not sure if this is implimented yet, but the idea was that th= e=20 compiler would check for the largest used type, and create the MATHx=20 registers this size. Right now it may just be #define'd somewhere. > Are function return addresses really placed on the stack? What about > function return values? I think the current code uses the hardware stack (for the PIC instructi= on=20 set). With the AVRs, it looks like a real stack (no hardware limits) wil= l be=20 possible. I would like this to be configurable, but it isn't yet. I think right now function return values are always in MATHB. MATHB is= =20 kind of the central point for all memory movement. =20 I'll be looking at gra1.y and gra_util.c next, since that is where the = work=20 to be done is. |
|
From: Patrick E. <pa...@pa...> - 2001-08-16 10:31:59
|
On Thursday 16 August 2001 00:36, you wrote:
> Oops. I thought I did the cvs add for that file a long time ago,
> but I didn't. It's there now.
Good stuff, I got it now.
> > Are static local variables also included in the fixed global
> > memory?
>
> I think so, although I'm not sure if they are in there yet. Is
> that the way it is normally done?
Well, they must maintain their state throughout the execution of the
program. That means they must have their own storage location. All
of the non-automatic storage locations, including globals and
statics, must be initialized to zero.
> > In 6.1.3 are the MATHx variables the size of the largest basic
> > type (ie. not arrays/structures)?
>
> Yes. I'm not sure if this is implimented yet, but the idea was
> that the compiler would check for the largest used type, and create
> the MATHx registers this size. Right now it may just be #define'd
> somewhere.
>
> > Are function return addresses really placed on the stack? What
> > about function return values?
>
> I think the current code uses the hardware stack (for the PIC
> instruction set). With the AVRs, it looks like a real stack (no
> hardware limits) will be possible. I would like this to be
> configurable, but it isn't yet. I think right now function return
> values are always in MATHB. MATHB is kind of the central point for
> all memory movement.
>
> I'll be looking at gra1.y and gra_util.c next, since that is
> where the work to be done is.
Do you know what needs done yet? It would be cool if you could think
of a few coding tasks to let me familiarize myself more with your
code.
Do you want to integrate what you said to me in your last e-mail into
the doc, or should I do that? I think perhaps it would be a good
idea to watch for interesting information in our e-mails and add that
to the docs as necsessary.
Have a nice day! :)
Patrick Earl - pa...@pa...
|
|
From: Daniel W. <dan...@ro...> - 2001-08-16 20:18:04
|
> > > Are static local variables also included in the fixed global > > > memory? > > > > I think so, although I'm not sure if they are in there yet. Is > > that the way it is normally done? > > Well, they must maintain their state throughout the execution of the > program. That means they must have their own storage location. All > of the non-automatic storage locations, including globals and > statics, must be initialized to zero. I think I was assuming that all non-automatic variables would be alloca= ted=20 at the start of memory, before the heap. I didn't realize non-automatic=20 variables were initialized to zero... It would be nice to put literals in the code memory to save space in th= e=20 data memory. I think I remember this being possible with PICs... > Do you know what needs done yet? It would be cool if you could think > of a few coding tasks to let me familiarize myself more with your > code. I think I'm going to have to sit down with the code more before I can t= ell=20 where to go next. Right now the main thing is getting the grammar correc= t,=20 although a lot of ANSI C has not even been started, such as structures. = Are=20 you familiar with yacc? I doubt if my grammar is even close to correct r= ight=20 now...=20 > Do you want to integrate what you said to me in your last e-mail into > the doc, or should I do that? I think perhaps it would be a good > idea to watch for interesting information in our e-mails and add that > to the docs as necsessary. It is fine if you want to add it, or I will get to it eventually if not= =2E I=20 think my efforts should stay in documentation for a while. That would he= lp=20 my understanding as well. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X