Searching \ for '[PIC] Mikropascal' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Mikropascal'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Mikropascal'
2004\10\22@124653 by Padu

face picon face
I'm a software engineer with lot's of Pascal experience (Pascal, Object Pascal and Delphi since version 1).
I found this mikropascal compiler for PICMicro and I'm very pleased with the resources it offers. For example, to send data using the USART it requires only two lines of code. It has libraries for basically anything you need (at least while you are learning, I suppose)

My question is: is anybody here using it to develop real applications? how long are they in the market? would you trust them for your compiler provider?

Thanks
___________________________________________

2004\10\22@133908 by John Ferrell

face picon face
There does not seem to be many of us Pascal types around. I have not got so
far as trying to burn the chip on my PicStart Plus, but I am close.
Everything I have tested on the Demo issue looks good.

With the Demo program good for 2K of hex, there is no great pressure to buy
it immediately.
Then there is the "Deal" with the hardware kit, it looks good too!

I wonder about how much effort will go into keeping it current as new chips
are announced.
Since it will accept inline asm, that may not be all that important.
$214 is a big step for us hobby types, but I think I am going to do it...


John Ferrell
http://DixieNC.US

{Original Message removed}

2004\10\22@153156 by Padu

face picon face
I already bought their easypic2 (very good, I'm enjoying a lot), then we'll
probably buy the compiler for $99 if that's the case. The point is: money is
not the problem, but commit to a product I don't know if will be around
tomorrow. Well, I think it's a risk.

I've been visiting their forum and they are very responsive, and looks like
they are working on new releases constantly. For example, my project
involves logging data to compact flash. They first came up with FAT
libraries, then with FAT16, and now they even have a complete ADC data
logging project available on their website.

Being a delphi programmer myself, I think I got used not being on the
mainstream (read C/C++), although I'm very proficient with those too.
Personal taste I guess.

Padu

.--. .- -.. ..-
{Original Message removed}

2004\10\22@194419 by William Chops Westfield

face picon face
On Oct 22, 2004, at 9:46 AM, Padu wrote:

> would you trust them for your compiler provider?

Hmm.  I found pascal to be pretty frustrating as a systems-programming
language, and have a hard time imagining that it would be better in an
embedded environment (mind you, we did some neat stuff with Pascal and
assembler combinations...)

I don't know that I'd "trust" ANY single compiler vendor if ongoing
support
was considered a critical issue.  But then, I don't recall if I've ever
seen the multitude of C compiler vendors specifically mentioned as an
advantage of C as a language.   Nor have I seen mention of a need to
test your code with multiple compilers if you're in "serious" business,
although it's probably a good idea.  :-(   Open source tools certainly
give one a good (if not terribly realistic) feeling that in the worst
case you can always maintain the tools yourself...

I would also think that pascal would need more "embedded extensions"
that might not be compatible between vendors of pascal compilers...

BillW

____________________________________________

2004\10\23@114046 by olin_piclist

face picon face
William Chops Westfield wrote:
> Hmm.  I found pascal to be pretty frustrating as a systems-programming
> language, and have a hard time imagining that it would be better in an
> embedded environment (mind you, we did some neat stuff with Pascal and
> assembler combinations...)

One of the problems of Pascal is defining exactly what that is.  The book by
Jensen and Wirth describes a language that was originally intended for
teaching, and by itself is frustrating to use.  I had some exposure to HP
Pascal around 1982 based pretty much on that book, and it was a real pain.
It left me with a strong aversion to Pascal.

When I got to Apollo Computer in 1986, I was surprised to see that their
system implementation language was Pascal.  My initial reaction was disgust,
but it turns out Apollo had made a few enhancements to basic Pascal, and it
was a very nice language.  Domain/OS was written in Pascal, with only a few
key routines in assembler.

When I left Apollo to start a company to commercialize some data
visualization software, we had to find a way to make some of the base code
written for Apollos be portable accross platforms.  This was a bit before
C++ was real.  The only language available on all the workstations at the
time was C.  I started converting a few modules to C but couldn't stand
losing lots of good information that could be explained to the Pascal
compiler that was not possible to define in C.  Instead, we ended up writing
a source to source translator that could read the Pascal code and create
code in whatever language was appropriate for each target machine.  We
started with the Apollo Pascal definition, deleted some of the
Apollo-specific features, and added a few features of our own to allow the
master souce code to be machine independent.  This worked very well.  We had
one code base in Pascal, and code for different machines was produced from
that 100% automatically.

It turned out to be useful to have our own master source code from which
machine-dependent code was produced on the fly for reasons other than to
change the language.  Each C compiler had its own little quirks, and these
could be coded into the translator back end for each target.  The
workarounds for compiler bugs would often have been tedious and error prone
if written by a human, but these are not problems when a machine is writing
the code.  The other advantage is that we essentially had our own language
that we could extend as needs arose.  We mostly did this to add portability
features.

I still use this same Pascal today.  I write Windows code in Pascal, which
gets translated to C, then compiled by the Microsoft Visual C++ compiler.
The only time I ever look at the C code is during debugging.  This is
actually not the big deal it may sound like.  I took a lot of care in the C
symbol generator to keep names the same as much as possible, and to make
them obvious when renaming was required.

By the way, the translator is called SST, and is included in the PIC
programmer development software at http://www.embedinc.com/picprg/sw.htm.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\23@201731 by William Chops Westfield

face picon face

On Oct 23, 2004, at 8:40 AM, Olin Lathrop wrote:

>  still use this same Pascal today.  I write Windows code in Pascal,
> which
> gets translated to C, then compiled by the Microsoft Visual C++
> compiler.
>

I assume that this C-emitting pascal compiler is not a commercial
product?

Do you happen to know the status of the pascal to C converters that are
available to normal people?  I think p2c is open source, and there may
be others?

Do you lose all the run-time checking Pascal was famous for when you
use such a package?  I don't know how well defined the runtime
environment
for pascal was defined, but C's is pretty clear ("there isn't one!")

BillW

____________________________________________

2004\10\24@110753 by olin_piclist

face picon face
William Chops Westfield wrote:
> I assume that this C-emitting pascal compiler is not a commercial
> product?

Actually it's not a compiler.  It translates Pascal source code to C source
code, which you still have to compile with a C compiler.  On the Windows
platform, the translater writes code for the Microsoft Windows Visual C++
compiler.

As for it being a commercial product, I guess not since I'm letting people
use it for free.  As I said, the translator and build scripts are included
in the PIC programmer development download at
http://www.embedinc.com/picprg/sw.htm.  I haven't created a release
specifically for it since I don't feel the documentation package is
complete.  You are welcome to give it a try.  The program is called SST, so
SST.EXE will be in the COM directory and SST.TXT in the DOC directory.  The
same software release also includes plenty of examples of Pascal source
code.

> Do you happen to know the status of the pascal to C converters that
> are available to normal people?  I think p2c is open source, and
> there may be others?

All I know is that way back when I wrote SST there was nothing industrial
strength out there.  There were one or two translators, but they were merely
glorified syntax converters.  The Pascal front end to SST contains the same
kind of logic a Pascal compiler front end would.  It doesn't just convert
syntax, but compiles the input source into in-memory structures that define
the code in a language independent way.  The translator back end then writes
out that code in the target language.  The back end doesn't start until the
front end completes.  The front and back ends are separable.  You could
teach it a different input and output language just by creating the
appropriate front or back end.

Everything available at the time I wrote SST seemed to be aimed at helping
you convert your Pascal to C code manually once.  My translator is designed
for continued Pascal development and the C code is intended to be a
temporary file rarely looked at by humans.

Even "normal" people should be able to download my translator, so I'm not
sure what you are getting at with that statement.  What you download is the
same fully functional program I use.  The biggest problem for "normal"
people is that the documentation assumes you know Apollo Pascal.  However,
there are plenty of SST Pascal examples, and it's not that different from
other Pascals.  If there is serious interest, I might even be willing to
make the source code available.  It's written in Pascal of course.  The
Pascal syntax is defined in my syntax description language, which is
implemented by a different front end of SST.

> Do you lose all the run-time checking Pascal was famous for when you
> use such a package?

Absolutely not!  That was the main reason for creating a translator instead
of converting all the code to C once.  I've even added a few features that
strengthen the translator's ability to detect programming errors.

> I don't know how well defined the runtime
> environment
> for pascal was defined, but C's is pretty clear ("there isn't one!")

Pascal has a lot more stuff built into the language than C.  I didn't
implement most of the Pascal I/O.  Instead, the C back end assumes the
existence of our OS interface libraries, SYS, UTIL, STRING and FILE.  These
and their include files are included with SST.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\24@163957 by William Chops Westfield

face picon face

On Oct 24, 2004, at 8:07 AM, Olin Lathrop wrote:

> Even "normal" people should be able to download my translator, so I'm
> not sure what you are getting at with that statement.

I had missed that this was part of the package you make available, and
assumed it was a left-over tool from a project/employer that was not
publicly accessible.  My mistake, and my apologies...


> Actually it's not a compiler.  It translates Pascal source code to
> C source code, which you still have to compile with a C compiler.
>
Hmm.  I might still consider it a compiler, depending on how it is
written/structured.  Just because the omitted code it another C level
language instead of object code doesn't mean it's not a compiler.

>
> The Pascal front end to SST contains the same kind of logic a Pascal
> compiler front end would.  It doesn't just convertsyntax, but compiles
> the input source into in-memory structures that define the code in a
> language independent way.

See?   There you go, it *is* a compiler...

I've occasionally wished for a compiler that would recognize the
assembly languages from obsolete architectures, as an alternative
to the the object-code emulators that seem to be popular.  I guess
it's a bit tricky, though...

BillW

____________________________________________

2004\10\24@193915 by olin_piclist

face picon face
William Chops Westfield wrote:
>> The Pascal front end to SST contains the same kind of logic a Pascal
>> compiler front end would.  It doesn't just convertsyntax, but
>> compiles the input source into in-memory structures that define the
>> code in a language independent way.
>
> See?   There you go, it *is* a compiler...

OK, if that's how you define a compiler.  I think of a compiler as something
that translates source code into machine or sometimes assembler code.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\24@201859 by Charles Craft

picon face
I skipped Compiler Construction (seemed too much like work) but the Dragon book
is probably the most noted reference of what a compiler is.

http://www.jargon.net/jargonfile/d/DragonBook.html

{Original Message removed}

2004\10\25@003304 by William Chops Westfield

face picon face

On Oct 24, 2004, at 5:18 PM, Charles Craft wrote:

> I think of a compiler as something that translates source code
> into machine or sometimes assembler code.
>
The compiler class I took was quite weak in the "code generation" area,
as opposed to formal languages (BNF), lexical analysis, and parsing.
They were very big on emitting an intermediate sort-of assembler syntax,
and I don't see why C couldn't qualify for that as well...

Wasn't C++ considered a compiler even back when it emitted C code?

Have you used the pascal "thing" to produce C code for PICs as well, or
is its structure pretty much limited to larger systems?

BillW

____________________________________________

2004\10\25@080320 by olin_piclist

face picon face
William Chops Westfield wrote:
> Have you used the pascal "thing" to produce C code for PICs as well, or
> is its structure pretty much limited to larger systems?

I used it on a 8051 project once, but not on PICs.  Actually I don't think
it would be that hard to create a MPASM back end for the translator.  Good
optimization is difficult, but just making it work doesn't sound too tough.
I can make the source code available if someone wants to try it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\25@220402 by Sergio Masci

flavicon
face
William Chops Westfield wrote:
>
> I've occasionally wished for a compiler that would recognize the
> assembly languages from obsolete architectures, as an alternative
> to the the object-code emulators that seem to be popular.  I guess
> it's a bit tricky, though...
>
> BillW

Do you mean convert the assembler source for architectures A to machine code for
architectures B?

e.g.
   Z80 input
       ld    A,(HL)
       ld    B,C

   PIC output
       movf    z80_reg_L,w
       movwf    FSR
       bsf    STATUS,IRP
       btfsc    z80_reg_H,0
       bsf    STATUS,IRP
       movf    INDF,w
       movwf    z80_reg_A

       movf    z80_reg_C,w
       movwf    z80_reg_B


If so, XCASM can already do this :-)

XCASM is the meta assembler used by the XCSB compiler and the PIC edition of
ZMech.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
LITE edition free for personal non-commercial use



____________________________________________


'[PIC] Mikropascal'
2004\11\08@085822 by John Ferrell
face picon face
I am curious about the nature of the install protection on this product.
If it is the type where I must supply a generated number to them and then
they provide a key, I can stop right here. If it is of the type that the key
provided with my copy is good for whatever machine I install on, I am still
interested.

The discussion on their discussion board implies one and only one install
without re-contacting them. I expect my use of the software to outlive their
support.

BTW, some of the Microsoft keys seem to be unnecessary after a few years!

John Ferrell
My Competition is not my enemy!
http://DixieNC.US

{Original Message removed}

2004\11\08@120057 by Padu

picon face
I'm still using their demo. I'm a pascal lover and a delphi programmer since
version one, therefore my affinity to pascal. Mikropascal's IDE looks a lot
(I mean "a lot") like delphi's. But you're right, the registration scheme is
tied to your hard drive, if you have to reinstall your software, you have to
contact them again (I'm 80% sure of that, but you'll want to check either
way). That's very annoying, but as a software engineer manager of a small
company I admit we've done things like this in my company too.

We've thought about some inovative ways to avoid piracy while not annoying
the customer, but that seems like a very hard task.



From: "John Ferrell"
> I am curious about the nature of the install protection on this product.
> If it is the type where I must supply a generated number to them and then
> they provide a key, I can stop right here. If it is of the type that the
key
> provided with my copy is good for whatever machine I install on, I am
still
> interested.
>
> The discussion on their discussion board implies one and only one install
> without re-contacting them. I expect my use of the software to outlive
their
> support.
>
> BTW, some of the Microsoft keys seem to be unnecessary after a few years!
>
> John Ferrell
> My Competition is not my enemy!
> http://DixieNC.US
>

____________________________________________

2004\11\08@124012 by Walter Banks

picon face



William Chops Westfield wrote:

> I've occasionally wished for a compiler that would recognize the
> assembly languages from obsolete architectures, as an alternative
> to the the object-code emulators that seem to be popular.  I guess
> it's a bit tricky, though...
>
> BillW

Bill

We have looked at this problem  in a lot of detail in automating the translation from one asm code to another.There are many real issues and approaches. The simplest approach is not very efficient it uses a macro for every instruction and then cross
assembles. It is an 80% solution where the user needs to check a lot of condition code usage that is not consistent between processors (In some cases even different members of the same processor family)

Byte Craft has had some success with two different solutions. The first (90%) solution changed the backend of an assembler into a Finite State Machine that accepted source code and emitted C by sorting out what the intentions was.

lda a
add b
sta c became

c = a +b kind of thing.

The FSM had a lot of states, several hundred, It worked but it was complex and I think hand translating would have been easier.

The last one was very interesting. What we did was write a formal grammar for the assembly and ran it through an interpretive compiler compiler that created a  little C statements for each asm statement taking advantage of some C standards for embedded
systems processors extensions

lda a
add b
sta c

 became

ac = a;
ac = ac + b;
c = ac;

We ran the generated code through a C compiler for the target processor. Most C compilers do quite well at optimizing this type of short statements.
When we did this for example between PIC and Freescale 6808 the 6808 code came out shorter than the original PIC object.  PIC asm to PIC target was also interesting. The main difference was removal of some redundant memory management instructions..

Regards


Walter..



____________________________________________

2004\11\08@180537 by James Newtons Massmind

face picon face
That is REALLY interesting. You leverage the power of the C compilers
optimizer to distil the source assembly...

Using C as an interim language that is common to all assembly languages...

I was working on a sort of assembly language "interpreter" (rather than a
true simulator) for the SX chip and found that using a sort of compressed
version of JavaScript, I could provide both an explanation of what the
assembly code did (this was an educational thing) and by translating that
description, I could get JavaScript to evaluate for the simulation of that
statement.

Actually, now that I look at the code, it was the other way 'round. I
started with JavaScript which I eval'd to execute the instruction, then
modified that to get a sort of English description of the effect.

function traceOut (string) {
       eval (string);
       string = string.split(".val").join("");
       string = string.split("SX.").join("");
       SX.TRACE.value += "\n -> "+string;
       }

Which would be called by

               case "SKIP":
                       traceOut("SX.PC.val++;"); break;

And that is JScript, I guess, not JavaScript.

In any case, the idea of describing one assembly language in terms of a
higher level language, and then using the HLA to do the work...

One of these days I should complete that project, it would be fun to watch a
small chunk of code execute in your browser while it's operation is
explained to you. No?

Maybe for a future issue of the mass mind newsletter.

---
James.



> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...