> On Fri, 7 Sep 2001, Byron A Jeff wrote:
>
> Personally I'd like to see straight assembly. ASM can be integrated into
> higher level languages, can run standalone, and doesn't lock users into a
> particular environment. For example I'm planning on resurrecting my NPCI
> programming language in the near future. Wouter's JAL could definitly benefit.
> Then there's the Basic crowd. The only common denominator is ASM. Think
> ASM library with whichever high level interface required...

I know the argument, and I can't say I disagree...  but I simply don't do assembler any more.  If I complete this, it will be for me -- if others get some use out of it, fine, but my position is basically if you want it in assembler you're going to have to write it yourself.  8-)  I simply don't have the time or desire to re-learn assembly to the point I could write something of this level of complexity without it looking like a joke.

> >   1. Have another set of standard functions to read and write bytes to
> > buffer space.  These functions would need to be modified to fit your
> > environment - either talk to the Crystal chip or use RAM buffers, or
> > external EEPROM or whatever.  Messy and a lot of work.
>
> Why is this messy? It's known as a device driver. And we're going to have to
> have them. By compartmentalizing them you can switch and swap, mix and match,
> drivers with the stack. DOS packet drivers and the Winsock stack became huge
> precisely because a well definied interface between the driver and the stack
> was available.

OK, now I see your point, have a function to fetch things from the buffer, or stuff them into it, and those functions would be part of the device driver and have the same interface regardless of what you're taking to.

> Drivers are the way to do. Define a clear robust interface between the stack
> and the driver. Then build all drivers to that spec. You will never ever
> regret it.

Gotcha.  I was just not thinking about the driver as containing some crucial bits of the code, which they obviously should.

> > Maybe I'm being too ambitious, but I want to write a code set exactly
> > once, that I can re-use without modification anywhere, any time, and
> > preferably on any processor.
>
> Agreed to a point. Personally I think it's more important to have a tool
> independent implementation that works on the vast majority of PIC products
> and can me applied in multiple language/development environments than it is
> to have a single language implementation that can be cross platform. Maybe
> in the end we'll need both.

For me, a single language approach works for exactly one reason - I'll actually DO it.  I don't write assembler code (used to, but not any more).  I suppose the resulting code could be translated into some pretty generic assembler by someone with the time and patience to do so.

Hmmm.  I can drop assembly code into my C programs, too bad you can't drop C code fragments into your assembler!  8-)

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body