"Dave Hansen" <iddw@hotmail.com> wrote in message
news:40055603.159257904@News.CIS.DFN.DE...
> I've never tried SDCC, I don't know its ins and outs, but as far as
> Keil is concerned...
>
> >
> >unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> >{
> > unsigned char no_more = FALSE;
> > xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
> >
> > do
> > {
> > no_more = (*buffer_loader)(packet_data_buffer);
> >
>
> It is a strange piece of code...
Yes it is. Perhaps I should place it in a wider context. I wanted a module
that would xmodem transfer a file through the serial port, and which was
sufficiently modular to be readily incorporated into any application,
whether it be the current project or some later development. The only
external requirement for this module was to be an application specific
function that would refill a data buffer until all data had been
sent. I pass the address of this external function into the finished and
tested xmodem module when I want to send the file, so that I don't have to
screw about with the xmodem library module each time I use it. Nothing
ground-breaking, just trying to think about code management.
> You are requesting a local auto variable be located in xdata. I
> wasn't aware Keil would accept that silently. From the limited
> context you've provided, I can't tell for sure, , but I would expect
> you meant "static xdata unsigned char..." Perhaps thats what Keil
> actually does.
Hmm. Keil seems to compile it like this without any fuss. If it stayed as an
auto I couldn't see a problem accessing the buffer from within the called
loader routine. Keil is quite probably doing something with it that I don't
understand just yet. Maybe the manual will shed some more light. There's
really no way for me to tell what Zelda does in this situation.
> Note that (in Keil) "unsigned char *" is a three-byte type, but "xdata
> unsigned char *" is only a two-byte type. Presumably Keil isn't
> complaining because it coerces the type conversion. Make sure that
> any function you pass to xmodem_tx expects an "unsigned char *" and
> not "xdata unsigned char *".
Yes your quite right about the "unsigned char *" being a 3 byte, generic
pointer in Keil. I believe that such a pointer can be used to point to
variables in any data space, including xdata. At run time, when you pass it
a memory location, the type of memory space is recorded in the third byte.
It's apparently a slower method than Keil's 2 byte pointer access, but has
the advantage that my external buffer filling function need not be modified
if I subsequently choose to store the packet data buffer elsewhere in
memory. The same code will just as easily work with a buffer located in the
data memory space as in the xdata space. As you have suggested, I will be
careful to only pass a function that expects an "unsigned char *" to the
xmodem_tx function as above.
Gee, a good compiler manual makes you sound like a real expert. Well, at
least it doesn't leave you looking such a prawn.
The discrepancy between an "xdata unsigned char" address being passed as an
actual parameter to the *buffer_loader function (which expects the address
of an "unsigned char") looks more and more like a stuff-up when viewed as
SDCC code. I remember being quite certain at the time of submitting it to
the SDCC mailing list, that this was how I had to address the situation with
Zelda, given my experience at that time. It looked odd when I re-posted it
here, but I left it that way. I really don't know now. To tell you the
truth, I don't think Zelda minds too much what a pointer references. The
snipet crashes the compiler no matter how you address the matter, so I guess
it's of no consequence.
Thanks for that one Dave.
Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph: +618 9354 1375
E-mail: vanluynm@iinet.net.au
vanluynm@cs.curtin.edu.au
Reply by Dave Hansen●January 14, 20042004-01-14
On Wed, 14 Jan 2004 15:47:39 +0800, "M.R.Van Luyn."
<vanluynm@nospam.ses.curtin.edu.au> wrote:
[...]
>ie. Why does this hang the compiler?
I've never tried SDCC, I don't know its ins and outs, but as far as
Keil is concerned...
It is a strange piece of code...
You are requesting a local auto variable be located in xdata. I
wasn't aware Keil would accept that silently. From the limited
context you've provided, I can't tell for sure, , but I would expect
you meant "static xdata unsigned char..." Perhaps thats what Keil
actually does.
Note that (in Keil) "unsigned char *" is a three-byte type, but "xdata
unsigned char *" is only a two-byte type. Presumably Keil isn't
complaining because it coerces the type conversion. Make sure that
any function you pass to xmodem_tx expects an "unsigned char *" and
not "xdata unsigned char *".
Regards,
-=Dave
--
Change is inevitable, progress is not.
Reply by M.R.Van Luyn.●January 14, 20042004-01-14
"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:400535C6.9911425B@yahoo.com...
> "M.R.Van Luyn." wrote:
> >
> ... snip ...
> >
> > ie. Why does this hang the compiler?
> >
> > unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> > {
> > unsigned char no_more = FALSE;
> > xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
> >
> > do
> > {
> > no_more = (*buffer_loader)(packet_data_buffer);
>
> For one thing, you are giving buffer_loader a parameter of type:
>
> xdata unsigned char /* whatever that may be */
>
> when it requires:
>
> unsigned char *
Thanks Chuck. I always enjoy your posts.
I was pretty sure that I was passing the address in memory of the first
element of the packet_data_buffer array, to the function pointed to by
buffer_loader (which has as it's formal parameter a pointer to an element of
type unsigned char). Neither Borland C++ (minus the xdata part), nor the
Keil toolset seemed to mind.
I will look it up, though. I recognise that the first stage in effective
learning is to admit that I may not know everything, and am sometimes wrong.
Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph: +618 9354 1375
E-mail: vanluynm@iinet.net.au
vanluynm@cs.curtin.edu.au
Reply by CBFalconer●January 14, 20042004-01-14
"M.R.Van Luyn." wrote:
>
... snip ...
>
> ie. Why does this hang the compiler?
>
> unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> {
> unsigned char no_more = FALSE;
> xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
>
> do
> {
> no_more = (*buffer_loader)(packet_data_buffer);
For one thing, you are giving buffer_loader a parameter of type:
xdata unsigned char /* whatever that may be */
when it requires:
unsigned char *
so at most you are complaining about compiler error handling. If
another compiler handles that without complaint it must be faulty.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Reply by Ian Bell●January 14, 20042004-01-14
M.R.Van Luyn. wrote:
> "Terry" <tjporter@gronk.porter.net> wrote in message
> news:usv7d1-vnn.ln1@gronk.porter.net...
>
>> It seems to me (and I could be wrong) that you used SDCC, didn't know
>> what you were doing, didn't read the manual and just gave up ?
>
> I did indeed give up on Zelda. I can assure you that for the 20 or so days
> that I struggled with it, that I made very good use of the manual. I
> cranked out only 70K of source in that time (very slow going), and on the
> last 3 days I got nowhere.
>
Now I *know* you are a troll.
Ian
Reply by M.R.Van Luyn.●January 14, 20042004-01-14
"Terry" <tjporter@gronk.porter.net> wrote in message
news:usv7d1-vnn.ln1@gronk.porter.net...
> It seems to me (and I could be wrong) that you used SDCC, didn't know
> what you were doing, didn't read the manual and just gave up ?
I did indeed give up on Zelda. I can assure you that for the 20 or so days
that I struggled with it, that I made very good use of the manual. I cranked
out only 70K of source in that time (very slow going), and on the last 3
days I got nowhere.
> Did you determine what wasn't happening correctly, did you submit
> a bug report ?
You reach a point with Zelda at which it is just impossible to tell why the
compiler hangs, generates bizarre code, or gives you insensible error
messages. Ultimately no amount of 'working around' problems or re-ordering
code will please the compiler. I'm not sure about bug reports, but I sent a
few queries in.
ie. Why does this hang the compiler?
unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
{
unsigned char no_more = FALSE;
xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
do
{
no_more = (*buffer_loader)(packet_data_buffer);
etc.
I sent in a few queries regarding the printf() function too. There's
basically nothing in the manual regarding this, and the mailing list replies
weren't altogether what I had hoped for.
Incidentally, the Keil compiler has no problem with the above snippet. Nor
the 'curious truth', nor printing floating point numbers, nor passing
structures, nor....
> SDCC is used by many people and the SDCC list is highly active. So I can't
> take your predictions seriously.
Yes, I subscribed to the mailing list for a month. On average there were 2
postings a day (most 6, least 0). Highly active? There seems to be a few
postings between the dedicated developers who are working feverishly to
improve Zelda, and then the predictable stream of "Gee, this is great...oh,
it's buggy...good luck guys. Seeya" type messages.
> I haven't had anything to defend in this case, I simply asked for reasons
> regarding your negative claims of SDCC, and so far you have not offered
one
> tangible reason.
I have no problem with that. I guess if I had logged each and every of the
numerous hiccups that I encountered, then I might be able to make a more
salient argument.
As it should be, it is then up to readers to make up their own minds. By all
means try SDCC. If you only use it as a lazy compiler (quite admirable in a
busy world, and with well resourced microcontrollers) then Zelda might be
for you. If you reach a level of familiarity at which you can appreciate the
'nick' Zelda, then you might think to cut your losses.
Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph: +618 9354 1375
E-mail: vanluynm@iinet.net.au
vanluynm@cs.curtin.edu.au
Reply by Chris Hills●January 13, 20042004-01-13
In article <4003746c$0$547$a1866201@newsreader.visi.com>, Grant Edwards
<grante@visi.com> writes
>In article <hqFap7CV0vAAFA8k@phaedsys.demon.co.uk>, Chris Hills wrote:
>
>> If it is open source, I have to test and validate the version I have.
>
>How is that any different than having to test and validate the
>verion you have of a commecial product?
Because it has already been tested with the plum hall suite and passed
so I don't have to do it.
>> I have no idea if the one I have is the tested version of if
>> some well meaning idiot has "adjusted" the source and
>> re-compiled it.
>>
>>>> I have no guarantees that it has not been "adjusted" buy some
>>>> well meaning idiot.
>>>
>>>You have no such guarantees with proprietary software either.
>>>In fact you have *less* guarantees as you don't have the source to
>>>check what's changed.
>>
>> Far more guarantees... unless you are suggesting the the commercia
>> companies lie?
>
>No, but their software has more bugs than open-source
>equivalents according to a number of fairly extensive studies.
>[Of course if you can't find an open-source equivalent, it's
>moot.]
I suppose you have figures to back that up? BTW this is for embedded
compilers.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Grant Edwards●January 13, 20042004-01-13
In article <hqFap7CV0vAAFA8k@phaedsys.demon.co.uk>, Chris Hills wrote:
> If it is open source, I have to test and validate the version I have.
How is that any different than having to test and validate the
verion you have of a commecial product?
> I have no idea if the one I have is the tested version of if
> some well meaning idiot has "adjusted" the source and
> re-compiled it.
>
>>> I have no guarantees that it has not been "adjusted" buy some
>>> well meaning idiot.
>>
>>You have no such guarantees with proprietary software either.
>>In fact you have *less* guarantees as you don't have the source to
>>check what's changed.
>
> Far more guarantees... unless you are suggesting the the commercia
> companies lie?
No, but their software has more bugs than open-source
equivalents according to a number of fairly extensive studies.
[Of course if you can't find an open-source equivalent, it's
moot.]
--
Grant Edwards grante Yow! -- I can do
at ANYTHING... I can
visi.com even... SHOPLIFT!!
Reply by CBFalconer●January 12, 20042004-01-12
Chris Hills wrote:
>
... snip ...
>
> I think for anyone who wants to experiment with a compiler, learn
> parsing etc it is a great learning tool but I would not use it
> for any commercial software.
>
> BTW as it happens I am involved in doing a test suite that will
> be GPL. It is not for compilers though.
I believe there exists a GPL C test suite for gcc. I know no
details.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Reply by Chris Hills●January 12, 20042004-01-12
In article <ualad1-3ak.ln1@gronk.porter.net>, Terry
<tjporter@gronk.porter.net> writes
>Chris Hills threw some tea leaves on the floor
> and this is what they wrote:
>
>> In article <usv7d1-vnn.ln1@gronk.porter.net>, Terry
>><tjporter@gronk.porter.net> writes
>>>M.R.Van Luyn. threw some tea leaves on the floor
>>> and this is what they wrote:
>>>Free Software is different to closed source, it requires that we *all*
>>>make it better by verifying bugs and then if we can't fix it ourselves,
>>>lodging a bug report with the maintainer.
>>
>> Therefore YOU as the user are responsible for all the code you ship
>> compiled with it.
>
>Are you not responsible for your code Chris ?
Yes. But my code does not include the compiler and validating it as
well.
>> The FDA rules on software will make it cheaper to use
>> the Keil than the SDCC for any medical project.
>I don't doubt you, but how is the FDA relevant in this thread ?
I have to work to FDA guidelines with some code. the requirements for
validating the compiler mean that I can use a validated commercial
compiler but could not afford to validate something like the SDCC.
>> This is the point. The commercial companies do fix problems and work
>> with customers.
>Do they ?
Yes.
>They certainly take your money. They certainly go broke or get taken
>over and dismantled, they certainly have key personel leave etc.
But in a company you can change personal and not loose anything. It is
not the same as passing an open source project around. Besides the
embedded tools companies tend to vet people working on their tools.
>> Many people use SDCC for two very important technical reasons.... it's
>> free and it runs on Linux..... the other one is that it is open source.
>> This makes it UN-USABLE for much of the work I do.
>
>Why ?
If it is open source, I have to test and validate the version I have. I
have no idea if the one I have is the tested version of if some well
meaning idiot has "adjusted" the source and re-compiled it.
>> I have no guarantees
>> that it has not been "adjusted" buy some well meaning idiot.
>
>You have no such guarantees with proprietary software either.
>In fact you have *less* guarantees as you don't have the source to
>check what's changed.
Far more guarantees... unless you are suggesting the the commercia
companies lie?
>> Has it been run on either of the main C test suites?
>> How does it cope with the paranoia test?
>> What testing has been done on it?
>
>Good questions, how do you answer them for your proprietary software ?
Yes. I can even quote the Plum-Hall Licence number for the compiler test
suite.
>> How much experience does he need to know it doesn't work?
>
>Are you claiming that SDCC "doesn't work" now ?
Not to the same level the commercial compilers do.
>I don't doubt you, but why is this an issue ?
this is where we started... It is probable (I don't have the chapter
and verse to quote so I wont say it is the case exactly) that Keil
compiler for example will produce executable that is half the size of
the SDCC. More to the point with data overlaying and correct handling of
integer promotion there are a lot of programs that will fit on chip in
an 8, 61, 32 or64K single chip part that wouldn't fit with the SDCC.
External memory is expensive. Also of course you loose port pins. that
could push the cost of the design up by a few dollars.. say one or
two.... now multiply that by a run of 10,000 units. Your "free" compiler
has just cost you 10,000 dollars.
>> It seems to have some serious short comings when compared to commercial
>> compilers.
>That remark is so general, I'll just ignore it.
I am glad you can afford to.
>> It has not AFAIK passed anything like the Plum-Hall or Perennial tests.
>Irrelevant for Free Software because of the proprietary nature of these
>test suites.
>The Plum Hall test suite requires licensing and hence it is not
>acceptable to Free Software. Same for the PERENNIAL Validation Suites.
This is like the primitive tribes (all long since gone) that said the
bullets of the un-believers could not hurt them.
I am not interested in your political/phiosophical beliefs. Which
industry accepted tests have been applied to the SDCC compiler? which
has it passed?
None. In other words it is not an industrial C compiler? your "opinion"
does not count. Can yo finds anyone (suitably qualified) who would
support that the SDCC compiler (as it is now) is suitable for industrial
use?
A test is a test 2+2=4 regardless if it is calculated with a FSF program
or a commercial one. Any program that gives an incorrect answer is
wrong. It is no use you whining that you don't like the test. the Plum-
Hall and Perennial are the industry wide test suites. If you want o play
in the industrial world you have to pass these. Or of course come up
with your own (Free) test suite that is also accepted as a test for
compilers.
The SDCC has very poor code density and is untested by any accepted
industry test suite. Therefore it is not relevant for any industrial
use. Just hobby use.
I think that is what I said to start with.
I think for anyone who wants to experiment with a compiler, learn
parsing etc it is a great learning tool but I would not use it for any
commercial software.
BTW as it happens I am involved in doing a test suite that will be GPL.
It is not for compilers though.
Regards
Chris.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/