Menu
▾
▴
anyc-devel — Discussion related to the development of the AnyC compiler
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
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. |
|
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 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 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 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: 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: 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-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-07-21 00:25:21
|
On Friday 20 July 2001 00:21, you wrote:
> I am going on vacation starting Saturday morning until next
> Saturday or Sunday. Since my girlfriend isn't going with me, I
> will print out the code and look at it when I'm recovering from the
> hikes. Hopefully then I will be up to speed again about how it
> works, so I can start a developers document with Lyx and be able to
> answer question better.
I'll have to write more about what I was talking about. I didn't
really explain my thoughts very well. I'm sure I'll have more ideas
by the time you come back. I'm going on a little trip myself at the
moment. It's only until tommorrow though. I'll try to write some
detailed replies to your messages soon. Have a good trip! :)
Patrick Earl
|
|
From: Daniel W. <dan...@ro...> - 2001-07-20 07:19:26
|
> With the PIC16F877, the data memory is fragmented. It you look on > page 13 of the pdf for it, you can see that the largest unfragmented > section is 112 bytes. Using the FSR and INDF alone, you can access > 176 actual bytes of data memory. The full amount of memory is 386 > bytes and can be accessed with the FSR and the IRP bit of the STATUS > register. The stack will have to know when it's going to hit a > boundary in order to jump to the next section. Alternatively, > variables could be pre-allocated in order that you don't have to > worry about hitting the end of the stack space. It's probably > possible to build some sort of psuedo-stack-machine in the compiler > that will deal with this fragmented data memory issue. Oh, ok. I didn't realize it was over 256 bytes. That explains why the= =20 data stack would also have some overhead. I still think that pre-allocat= ing=20 memory for local variables is a bad idea, unless the program doesn't use = much=20 of the available memory (in which case, you should be buying a cheaper mo= del=20 of PIC, right?). Also, the easy way to parse expressions is on the stack= =2E =20 I'm not really sure how I would do expression parsing without a stack. =20 > Limited recursion using the hardware stack is possible on the 877, > since it has 8 levels of stack. I'm more worried about the data > issues than the difficulties with the hardware stack. Now I see what you mean... I don't think the original PIC architecture = was=20 ever designed with the idea of having more than 256 bytes of memory. =20 Obviously they have just taken the old core and tacked new things on top.= =20 Kind of like the 8086 processor line. > I get my chips at Active Components. It's a division of the company > that runs www.future-active.com. It's a local store... I generally > just drive over and pick up the parts I want. They happen to stock > the 877 and the 84, so it makes it easy for me to acquire them. I > could always special order things, but that's another step. There is a nice electronics store down the street from me, but I'm not = sure=20 what microcontrollers they carry. I used to live in Fayetteville, Arkans= as,=20 which has about zero chance of anyone carrying microcontrollers locally. > One issue is that I just got my PIC programmer to work under Linux. > It took me a while to find something that would work to program the > PIC16F877 under Linux. I spent more than a week unsucessfully trying > to program the PIC, until I finally had success with the NOPPP > programmer and the 16F84, which then required some hardware and > software adjustments to work with the 877. If you want, you can read > about what I did at http://patearl.net/pic_html > > I'm not in much of a hurry to build another programmer and buy more > chips. I don't have a lot of money at the moment, as I'm saving up > to buy a welder with my friend. Yikes. So far I haven't even programmed any chips, despite the fact th= at I=20 built a programmer from a kit several years ago. I worked with the 68HC1= 1=20 when I was doing microcontroller stuff at Los Alamos for my research, and= it=20 was an evaluation board that was pretty much ready to go. I suspected th= at=20 actually getting PIC programming to work might be difficult, which is why= I=20 put it off. > That said, the AVR chips sound quite delightful, and under other > circumstances, I'd probably jump at the opportunity to use them. As > for now though, getting the PIC to work nicely is, to me, a fun > challenge. I enjoy taking limited resources and making them work > well. That was the main reason I started the project in the first place. It = is=20 definetly a challenge to get such a simple processor to run C code with=20 floating-point and all. There are a lot of cool things I would like to d= o=20 with it too. > I've been studying the output from the compiler. It's pretty icky in > terms of speed. I don't even understand parts of it. I still need > to read more of it, but I'll probably have some questions for you, if > you think you can answer them. You mean the compiler is slow or the generated code would run slow on t= he=20 PIC? The compiler if for sure slow... my symbol table isn't even a hash=20 table, it's a linked list that has to search the whole thing for each sym= bol=20 lookup! Obviously this will need to be changed eventually. I didn't do = that=20 originally because I didn't want to write a hash table. Now that I have=20 learned about glib this will be much easier. I am going on vacation starting Saturday morning until next Saturday or= =20 Sunday. Since my girlfriend isn't going with me, I will print out the co= de=20 and look at it when I'm recovering from the hikes. Hopefully then I will= be=20 up to speed again about how it works, so I can start a developers documen= t=20 with Lyx and be able to answer question better. |
|
From: Patrick E. <pa...@pa...> - 2001-07-19 08:24:07
|
On Wednesday 18 July 2001 12:49, you wrote: > > I would be interested in making it possible to work with both > > situations. I imagine it would be possible to do with some sort > > of generic variable request system. If you need a variable, you > > ask it for code to get to that variable. It decides if it's > > going to be local or global in scope based on if the processor > > supports local variables/recursion. I haven't thought about it > > that much yet. > > I think you may be getting two different things confused, or else > I don't understand what you're saying. Since the PICs have > separate data and code memory, there are separate data and code > stacks. You can still implement a data stack (up to 256 bytes) > with the PICs. In fact, I really don't see any other way to make a > proper C compiler except to use a data stack. The reason is: the > compiler has no way to know what way the independent functions will > be called. Maybe function A will call function B, or C will call > A, which will then call B. Because of this, there are only two > options I see for local variables: > 1) Use a data stack for all local variables > 2) Allocate space for all local variables on the heap at run-time. > This means you will be using data space for every local variable in > every function all the time, whether that function is running or > not. I think I had a routine that would implement a data stack on > the PICs in the code, although I'm not sure. With the PIC16F877, the data memory is fragmented. It you look on page 13 of the pdf for it, you can see that the largest unfragmented section is 112 bytes. Using the FSR and INDF alone, you can access 176 actual bytes of data memory. The full amount of memory is 386 bytes and can be accessed with the FSR and the IRP bit of the STATUS register. The stack will have to know when it's going to hit a boundary in order to jump to the next section. Alternatively, variables could be pre-allocated in order that you don't have to worry about hitting the end of the stack space. It's probably possible to build some sort of psuedo-stack-machine in the compiler that will deal with this fragmented data memory issue. > So that data stack is not the problem. The problem is that the > code stack is either limited to the hardware stack, or you have to > do an incredible amount of work to get around it and implement it > in software. With the PICs, this is very difficult, which is why > no one has done it. With the AVRs, it looks much, much easier. It's possible to do, but I doubt it would be worth it. With the chips not natively supporting it, it would be pretty lame to generate a slow software solution when a better idea would be for the programmer to rewrite their code to not use recursion. Recursion certainly isn't a requirement, and probably wouldn't help with 99.5% of the appplications of the PIC. Limited recursion using the hardware stack is possible on the 877, since it has 8 levels of stack. I'm more worried about the data issues than the difficulties with the hardware stack. > All the work I did on the original version was centered around > the PIC line, but seeing the AVR datasheets makes the PICs seem > very old-fashioned. I would still like to support the PICs, I'm > just not sure they will ever be able to do what the AVRs can. > > Where do you get your chips? The major sources for amateur > electronics I have found are Digikey, Mouser, and Jameco. Digikey > now sells several of the AVR (two pages worth), including some with > no RAM or EEPROM for $2. Those might be interesting to implement a > virtual machine on eventually... I get my chips at Active Components. It's a division of the company that runs www.future-active.com. It's a local store... I generally just drive over and pick up the parts I want. They happen to stock the 877 and the 84, so it makes it easy for me to acquire them. I could always special order things, but that's another step. > I think I read on the Atmel site that the AVRs were designed with > C compilers in mind... that's why they have 32 general-purpose > registers. I have not done optimization work, but I can see how 32 > GP registers would make optimization much more efficient. They are > rated at 4 or 8 Mhz, but they are designed like the Scenix chips, > which means many of the instructions are 1 instruction per clock > cycle. The PICs use the traditional method which requires 4 clock > cycles per instruction. So actually the AVRs should be faster than > the PICs at top speed. If you count the reduction in overhead for > the data stack and the 32 GP registers, I guess the AVRs should be > 2-5 times faster for C code. One issue is that I just got my PIC programmer to work under Linux. It took me a while to find something that would work to program the PIC16F877 under Linux. I spent more than a week unsucessfully trying to program the PIC, until I finally had success with the NOPPP programmer and the 16F84, which then required some hardware and software adjustments to work with the 877. If you want, you can read about what I did at http://patearl.net/pic_html I'm not in much of a hurry to build another programmer and buy more chips. I don't have a lot of money at the moment, as I'm saving up to buy a welder with my friend. That said, the AVR chips sound quite delightful, and under other circumstances, I'd probably jump at the opportunity to use them. As for now though, getting the PIC to work nicely is, to me, a fun challenge. I enjoy taking limited resources and making them work well. I've been studying the output from the compiler. It's pretty icky in terms of speed. I don't even understand parts of it. I still need to read more of it, but I'll probably have some questions for you, if you think you can answer them. > Did you say you are in Canada? I'm not sure where Digikey sells > to, but I imagine you can get them through Digikey. They are a > little high priced, but the service is excellent (fast delivery and > phone help if you need it). > > Digikey is www.digikey.com and Atmel is www.atmel.com. Ya, I'm in Canada. I'll have to try ordering from DigiKey sometime. I keep hearing about them. Look forward to hearing from you once again. Patrick Earl |
|
From: Daniel W. <dan...@ro...> - 2001-07-18 19:47:10
|
> I would be interested in making it possible to work with both > situations. I imagine it would be possible to do with some sort of > generic variable request system. If you need a variable, you ask it > for code to get to that variable. It decides if it's going to be > local or global in scope based on if the processor supports local > variables/recursion. I haven't thought about it that much yet. I think you may be getting two different things confused, or else I don= 't=20 understand what you're saying. Since the PICs have separate data and cod= e=20 memory, there are separate data and code stacks. You can still implement= a=20 data stack (up to 256 bytes) with the PICs. In fact, I really don't see = any=20 other way to make a proper C compiler except to use a data stack. The re= ason=20 is: the compiler has no way to know what way the independent functions wi= ll=20 be called. Maybe function A will call function B, or C will call A, whic= h=20 will then call B. Because of this, there are only two options I see for=20 local variables: 1) Use a data stack for all local variables 2) Allocate space for all local variables on the heap at run-time. This=20 means you will be using data space for every local variable in every func= tion=20 all the time, whether that function is running or not. I think I had a=20 routine that would implement a data stack on the PICs in the code, althou= gh=20 I'm not sure. So that data stack is not the problem. The problem is that the code st= ack=20 is either limited to the hardware stack, or you have to do an incredible=20 amount of work to get around it and implement it in software. With the P= ICs,=20 this is very difficult, which is why no one has done it. With the AVRs, = it=20 looks much, much easier. All the work I did on the original version was centered around the PIC=20 line, but seeing the AVR datasheets makes the PICs seem very old-fashione= d. =20 I would still like to support the PICs, I'm just not sure they will ever = be=20 able to do what the AVRs can. Where do you get your chips? The major sources for amateur electronics= I=20 have found are Digikey, Mouser, and Jameco. Digikey now sells several of= the=20 AVR (two pages worth), including some with no RAM or EEPROM for $2. Thos= e=20 might be interesting to implement a virtual machine on eventually... > The AVR line sounds pretty good for compilers. I wonder if they had > compilers in mind when they were designed. Perhaps to act more like > regular computers. I don't want to only support the AVR line though, > especially since I don't even know if I can easily aquire them > locally without special ordering them. The PIC is a popular chip, > and having a free compiler for it couldn't hurt at all. :) I didn't > look at the datasheets for the AVR chips. I suppose they support > 20MHz as well? That was the only question I had about them. Perhaps > I should take a look when thinking about these memory allocation > issues. I think I read on the Atmel site that the AVRs were designed with C=20 compilers in mind... that's why they have 32 general-purpose registers. = I=20 have not done optimization work, but I can see how 32 GP registers would = make=20 optimization much more efficient. They are rated at 4 or 8 Mhz, but they= are=20 designed like the Scenix chips, which means many of the instructions are = 1=20 instruction per clock cycle. The PICs use the traditional method which=20 requires 4 clock cycles per instruction. So actually the AVRs should be=20 faster than the PICs at top speed. If you count the reduction in overhea= d=20 for the data stack and the 32 GP registers, I guess the AVRs should be 2-= 5=20 times faster for C code. Did you say you are in Canada? I'm not sure where Digikey sells to, bu= t I=20 imagine you can get them through Digikey. They are a little high priced,= but=20 the service is excellent (fast delivery and phone help if you need it). Digikey is www.digikey.com and Atmel is www.atmel.com. |
|
From: Patrick E. <pa...@pa...> - 2001-07-18 08:35:12
|
On Wednesday 18 July 2001 00:07, you wrote:
> I have looked into this in the past. You definitely can't do it
> easily, because the PICs are designed to use the hardware stack.
> To impliment a software stack (which is what is needed for
> recursion), it is nice to be able to read the program counter. If
> you allow your code to be non-relocatable, the compiler will know
> the absolute address of all the commands, and thus the program
> counter for each command. It would then theoretically be possible
> to save the high bits of the program counter somewhere. This would
> be quite tedious, it seems to me.
>
> The AVR line, on the other hand, seems to allow reading of the PC
> in an indirect way: if you call a function, the address is pushed
> (in two bytes) onto the stack. You can then pop the stack into
> register space and play with it. This makes a true software stack
> for both code and data possible.
>
> Have you had a chance to look at the AVR datasheets yet? I'm
> looking at the instruction set doc, and the 90S1200 and 90S8535
> (doc is the same as 90S4433).
>
> I'm unsure how hard it would be to make the compiler work for
> both situations... maybe not that hard.
I would be interested in making it possible to work with both
situations. I imagine it would be possible to do with some sort of
generic variable request system. If you need a variable, you ask it
for code to get to that variable. It decides if it's going to be
local or global in scope based on if the processor supports local
variables/recursion. I haven't thought about it that much yet.
The AVR line sounds pretty good for compilers. I wonder if they had
compilers in mind when they were designed. Perhaps to act more like
regular computers. I don't want to only support the AVR line though,
especially since I don't even know if I can easily aquire them
locally without special ordering them. The PIC is a popular chip,
and having a free compiler for it couldn't hurt at all. :) I didn't
look at the datasheets for the AVR chips. I suppose they support
20MHz as well? That was the only question I had about them. Perhaps
I should take a look when thinking about these memory allocation
issues.
Patrick Earl
|
|
From: Daniel W. <dan...@ro...> - 2001-07-18 07:05:45
|
> I've been investigating the elusive problem of doing recursion on > these chips. I decided I'd look to see how other compilers did it. > It turns out that NO compilers implement recursion on the PIC chips. > It really isn't that practical in any case. It could probably be > done via some trickery, but the results would be rather useless. > Recursion isn't really a demanded feature for such a small system in > any case. My current thoughts are to issue a warning if a recursive > call is used, and otherwise basically not support recursion for the > PIC. Does this seem like a decent way to go? I have looked into this in the past. You definitely can't do it easily= ,=20 because the PICs are designed to use the hardware stack. To impliment a=20 software stack (which is what is needed for recursion), it is nice to be = able=20 to read the program counter. If you allow your code to be non-relocatabl= e,=20 the compiler will know the absolute address of all the commands, and thus= the=20 program counter for each command. It would then theoretically be possibl= e to=20 save the high bits of the program counter somewhere. This would be quite= =20 tedious, it seems to me. The AVR line, on the other hand, seems to allow reading of the PC in an= =20 indirect way: if you call a function, the address is pushed (in two bytes= )=20 onto the stack. You can then pop the stack into register space and play = with=20 it. This makes a true software stack for both code and data possible. Have you had a chance to look at the AVR datasheets yet? I'm looking a= t=20 the instruction set doc, and the 90S1200 and 90S8535 (doc is the same as=20 90S4433). =20 I'm unsure how hard it would be to make the compiler work for both=20 situations... maybe not that hard. |
|
From: Patrick E. <pa...@pa...> - 2001-07-17 07:25:46
|
I've been investigating the elusive problem of doing recursion on
these chips. I decided I'd look to see how other compilers did it.
It turns out that NO compilers implement recursion on the PIC chips.
It really isn't that practical in any case. It could probably be
done via some trickery, but the results would be rather useless.
Recursion isn't really a demanded feature for such a small system in
any case. My current thoughts are to issue a warning if a recursive
call is used, and otherwise basically not support recursion for the
PIC. Does this seem like a decent way to go?
Patrick Earl
|
|
From: Patrick E. <pa...@pa...> - 2001-07-16 07:48:26
|
I have finally added CPP support. It took a bit longer than
anticipated as I didn't understand that I would be getting some extra
output from CPP and because I had to implement a C string parser.
The parser should come in handy for string literals too.
I made the following changes to the version of the compiler in the
CVS:
* Added cpp support
* Modified error/warning message format, added another error routine.
* Added preprocessor directive parsing support.
* Added missing newline to Generating Library output.
* Added C string parsing capabilities
* Made the file/line redirection messages from the preprocessor work.
* Fixed the duplicate memory_type problem.
It should also be noted that doing the parsing for the #pragma
directives is trivial at this point. All the routines are in place
to handle it. I'm quite pleased with the results. Here's a sample
from the new output:
[patearl@patmain anyc]$ ./anyc input.c output.asm
input.h:3: warning: Ignoring #pragma
input.c:4: warning: Ignoring #pragma
input.c:13: warning: Implicit type conversion
input.c:20: error: Assignment to invalid expression
input.c:21: error: invalid lvalue (assignment invalid)
input.c:33: warning: bitwise operator used on signed type
input.c:35: warning: Implicit type conversion
input.c:36: error: Can't mix signed and unsigned types without cast
input.c:36: warning: Implicit type conversion
input.c:38: warning: Implicit type conversion
Generating Library:
.........................................................................................................................................................................
[patearl@patmain anyc]$
Notice the warning from the #included header file. The
multi-file/line error message support is shown here also. A simple
pragma parser can be placed in the section of the code that currently
outputs that "Ignoring" message.
Have a nice day.
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: 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 00:31:08
|
I replaced the makeshift command line argument parser with the=20 standard gnu getopt_long parser. I also added a usage message to go=20 along with it. Next, I'm going to work on getting the compiler to=20 run the code through cpp. Have you had a chance to try out the code yet? >>> That is great! I haven't had time to look at the code except a peek. = I=20 have family visiting, and next week is vacation, and a big presentation n= ext=20 Friday. I'm looking forward to just having research to worry about, alon= g=20 with some free time. I'm not sure if I have the listserver working right for me yet. I didn= 't=20 get this message in my mailbox, and the message I sent to the list bounce= d=20 with the error (I changed my email to avoid spam): =A0 =A0----- Transcript of session follows ----- =2E.. while talking to mail.sourceforge.net.: >>>=A0MAIL From:<daniel****@robust.colorado.edu> SIZE=3D738 <<<=A0451 rejected: temporarily unable to verify envelope sender address = (try=20 again later) <daniel****@robust.colorado.edu> =2E.. while talking to externalmx.valinux.com.: >>>=A0MAIL From:<daniel****@robust.colorado.edu> SIZE=3D738 <<<=A0451-Envelope sender verification failed <<<=A0451 rejected: temporarily unable to verify envelope sender address = (try=20 again later) <daniel****@robust.colorado.edu> <any...@li...>... Deferred: 451-Envelope sender=20 verification failed Warning: message still undelivered after 4 hours Will keep trying until message is 3 days old =20 This may just be because sendmail was down on robust today. I think it= =20 should be working again now. =20 |
|
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-15 20:35:40
|
I replaced the makeshift command line argument parser with the
standard gnu getopt_long parser. I also added a usage message to go
along with it. Next, I'm going to work on getting the compiler to
run the code through cpp.
Have you had a chance to try out the code yet?
Patrick Earl
|