Searching \ for '[PIC] MAPM' 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: 'MAPM'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] MAPM'
2009\01\11@230405 by solarwind

picon face
How hard do you guys think it will be to port this:
http://www.tc.umn.edu/~ringx004/mapm-main.html (MAPM) to PIC C? It's
an arbitrary precision math library with all the functionality I need.
It has been stated that the library has proven to be very portable,
but we're talking about 8 bit PICs here...

--
solarwind

2009\01\12@001607 by Sean Breheny

face picon face
On a quick look, it looks doable, probably with a moderate amount of
frustration since PIC compilers almost never implement true ANSI C. I
saw some mention of ram allocation and stack use. You would have to
implement you own manual data stack and there may not be enough ram on
many PICs to run some of those routines, especially the FFT multiply
(which you don't need anyway since it optimizes for speed).

Sean


On Sun, Jan 11, 2009 at 11:03 PM, solarwind <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
> How hard do you guys think it will be to port this:
> http://www.tc.umn.edu/~ringx004/mapm-main.html (MAPM) to PIC C? It's
> an arbitrary precision math library with all the functionality I need.
> It has been stated that the library has proven to be very portable,
> but we're talking about 8 bit PICs here...
>
> --
> solarwind
> -

2009\01\12@012926 by solarwind

picon face
On Mon, Jan 12, 2009 at 12:15 AM, Sean Breheny <.....shb7KILLspamspam@spam@cornell.edu> wrote:
> On a quick look, it looks doable, probably with a moderate amount of
> frustration since PIC compilers almost never implement true ANSI C. I
> saw some mention of ram allocation and stack use. You would have to
> implement you own manual data stack and there may not be enough ram on
> many PICs to run some of those routines, especially the FFT multiply
> (which you don't need anyway since it optimizes for speed).
>
> Sean

HITECH promises ANSI C compatibility and I'm pretty sure Microchip C18
is similar.

--
solarwind

2009\01\12@115926 by Tamas Rudnai

face picon face
> HITECH promises ANSI C compatibility and I'm pretty sure Microchip C18
> is similar.

This might be true only on source level, however, as Sean mentioned:

>> PIC compilers almost never implement true ANSI C. I
>> saw some mention of ram allocation and stack use.

.. for example with PIC you can have a memory location of 0 as a valid RAM
address, which is against the ANSI standard (NULL pointer...). ANSI C was
designed on Neumann architecture not on Harvard so there is a confusion on
program memory an RAM pointers... Also as some compilers use the so called
pseudo-stack it is impossible to use functions as reentrant which leads
difficulties sometimes. Just to name of few.

Tamas

2009\01\12@120827 by Rolf

face picon face
solarwind wrote:
> On Mon, Jan 12, 2009 at 12:15 AM, Sean Breheny <shb7spamKILLspamcornell.edu> wrote:
>  
>> On a quick look, it looks doable, probably with a moderate amount of
>> frustration since PIC compilers almost never implement true ANSI C. I
>> saw some mention of ram allocation and stack use. You would have to
>> implement you own manual data stack and there may not be enough ram on
>> many PICs to run some of those routines, especially the FFT multiply
>> (which you don't need anyway since it optimizes for speed).
>>
>> Sean
>>    
>
> HITECH promises ANSI C compatibility and I'm pretty sure Microchip C18
> is similar.
>
>  
Well then, you should read the section in the C18 manual where it
documents most of the many deviations from ANSI... though there are
typically switches in C18 to make it cope with closer-to-ansi code.

Section 2.7 and 2.8 as well as appendix B all document deviations,
extensions, and implementation details of how C18 differs from ISO C...

See the C Pomiler USer's guide found here:

http://www.microchip.com/Microchip.WWW.SecureSoftwareList/secsoftwaredownload.aspx?device=en010014&lang=en#

Rolf


2009\01\12@124011 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tamas Rudnai wrote:
> .. for example with PIC you can have a memory location of 0 as a valid RAM
> address, which is against the ANSI standard (NULL pointer...).
>


This is only a problem should the C compiler choose 0x00000000 as the
internal representation of the null pointer. This is NOT required by ISO
C. A sensible choice of null pointer on a PIC might be all-bits-one of
an appropriate size. It is only required that a literal 0 at source
level used in a pointer context be translated to the appropriate bit
representation.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklrgGYACgkQXUF6hOTGP7dzBwCghBsL7C8WFZbePB7To0qSKVau
6SUAoJ542r4yAN37rmqW5lESifecpcvn
=Y6nT
-----END PGP SIGNATURE-----

2009\01\12@130556 by Wouter van Ooijen

face picon face
> .. for example with PIC you can have a memory location of 0 as a valid RAM
> address, which is against the ANSI standard (NULL pointer...).

But there is no requirement that NULL is is the address of memory
location 0, nor that NULL is represented by all bits 0, so this poses no
problem.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\01\12@143248 by Tamas Rudnai

face picon face
> But there is no requirement that NULL is is the address of memory
> location 0, nor that NULL is represented by all bits 0, so this poses no
> problem.

But then you should forget things like this:

if ( pointer ) { ... }

and instead always use like:

if ( NULL == pointer ) { ... }

BTW, this is the declaration from stddef.h (C18):

/* NULL is a simple one. Many compilers define NULL as ((void*)0), which
* is not best. A pointer to void is a pointer to data and a comparison
* to a function pointer is a type mismatch and should result in an
* error. The ANSI/ISO standard makes no guarantees about pointers to
* data and pointers to code being at all related to one another.
*
* Since the standard requires that a pointer comparison to an integral
* constant value of zero be allowed and is equivalent to a comparison
* to the NULL pointer constant, we define NULL very simply, as '0'.
*/
#define NULL 0

Tamas




On Mon, Jan 12, 2009 at 6:05 PM, Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl> wrote:

{Quote hidden}

> -

2009\01\12@144652 by M. Adam Davis

face picon face
Hm, I thought you were headed towards Pic32, but at the bottom you
mention 8 bit PICs.

If you're going to use an 8 bit PIC, I don't think your time is worth
it, porting MAPM over.  On top of trying to simulate a stack and
malloc, you're going to run into type issues where int may not be int.

I don't think you'll have much difficulty porting it to, say, PIC32.
But trying to run an existing arbitrary precision math package on a
small memory 8 bit device seems somewhat challenging.  You should
probably write your own in this case.

-Adam

On Sun, Jan 11, 2009 at 11:03 PM, solarwind <EraseMEx.solarwind.xspam_OUTspamTakeThisOuTgmail.com> wrote:
> How hard do you guys think it will be to port this:
> http://www.tc.umn.edu/~ringx004/mapm-main.html (MAPM) to PIC C? It's
> an arbitrary precision math library with all the functionality I need.
> It has been stated that the library has proven to be very portable,
> but we're talking about 8 bit PICs here...
>
> --
> solarwind
> -

2009\01\12@162130 by Wouter van Ooijen

face picon face
Tamas Rudnai wrote:
>> But there is no requirement that NULL is is the address of memory
>> location 0, nor that NULL is represented by all bits 0, so this poses no
>> problem.
>
> But then you should forget things like this:
>
> if ( pointer ) { ... }
>
> and instead always use like:
>
> if ( NULL == pointer ) { ... }

No. A compiler can use for instance the bit pattern -1 to represent
NULL, and still be ANSI C, and make both of the above forms work. The
magic is in the fact that 0 and (anytype*)0 need no be the same bit pattern.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\01\12@163103 by solarwind

picon face
On Mon, Jan 12, 2009 at 2:46 PM, M. Adam Davis <stienmanspamspam_OUTgmail.com> wrote:
> Hm, I thought you were headed towards Pic32, but at the bottom you
> mention 8 bit PICs.
>
> If you're going to use an 8 bit PIC, I don't think your time is worth
> it, porting MAPM over.  On top of trying to simulate a stack and
> malloc, you're going to run into type issues where int may not be int.
>
> I don't think you'll have much difficulty porting it to, say, PIC32.
> But trying to run an existing arbitrary precision math package on a
> small memory 8 bit device seems somewhat challenging.  You should
> probably write your own in this case.
>
> -Adam

Hmm, that brings up an interesting point. Either way, MAPM seems
interesting. I had that link bookmarked for two years and never looked
at it until recently. I'll be porting MAPM to PIC16F first and if that
proves to be too tough, I'll port it to PIC32 when it arrives at my
house.

--
solarwind

2009\01\12@163241 by solarwind

picon face
Sometimes I wish I'd just gotten an ARM7. But they use too much power,
way more than PICs anyway...

2009\01\12@163742 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote:
> Tamas Rudnai wrote:
>>> But there is no requirement that NULL is is the address of memory
>>> location 0, nor that NULL is represented by all bits 0, so this poses no
>>> problem.
>> But then you should forget things like this:
>>
>> if ( pointer ) { ... }
>>
>> and instead always use like:
>>
>> if ( NULL == pointer ) { ... }
>
> No. A compiler can use for instance the bit pattern -1 to represent
> NULL, and still be ANSI C, and make both of the above forms work. The
> magic is in the fact that 0 and (anytype*)0 need no be the same bit pattern.
>

I'm not fluent in C, but generaly speaking NULL means
"lack of value", not zero (or any other value). In databases
it usual to have a special bit that signals NULL, since one can
not use a value in the variable itself. But those fields are not
pointers, on the other hand, and C probably has a slightly
different meaning of "NULL"...

2009\01\12@164638 by solarwind

picon face
On Mon, Jan 12, 2009 at 4:37 PM, Jan-Erik Soderholm
<@spam@jan-erik.soderholmKILLspamspamtelia.com> wrote:
> I'm not fluent in C, but generaly speaking NULL means
> "lack of value", not zero (or any other value). In databases
> it usual to have a special bit that signals NULL, since one can
> not use a value in the variable itself. But those fields are not
> pointers, on the other hand, and C probably has a slightly
> different meaning of "NULL"...

http://bytes.com/groups/c/213647-null-c

--
solarwind

2009\01\12@171212 by Bob Blick

face
flavicon
face
On Mon, 12 Jan 2009 16:32:01 -0500, "solarwind"
<KILLspamx.solarwind.xKILLspamspamgmail.com> said:
> Sometimes I wish I'd just gotten an ARM7. But they use too much power,
> way more than PICs anyway...

MSP430 is a good compromise - 16 bits and very low power, nice
architecture and instruction set.

Cheerful regards,

Bob

--
http://www.fastmail.fm - Choose from over 50 domains or use your own

2009\01\13@044316 by Tamas Rudnai

face picon face
> No. A compiler can use for instance the bit pattern -1 to represent
> NULL, and still be ANSI C, and make both of the above forms work. The
> magic is in the fact that 0 and (anytype*)0 need no be the same bit
pattern.

Am I the only one who thinks that the most pervert man on Earth was the one
who invented this equation: 0 != 0 ...?

The origin of this was that it is very easy to initialize a memory area with
memset or such, so that a large portion of the variables could be
initialized without any fancy thing. Then if there is a pointer stored on
that area we can be sure that the pointer is invalid, as it was 0 (I mean
zero). But if NULL is != 0 (I mean zero) then this also fails, which leads
to problems. I think that it was not so random that the address of INDF
become 0 on 16F...

Anyway, just as an interesting side note: On my mother tongue zero is called
nulla - and my mother tongue is a bit older than C :-)

Tamas


On Mon, Jan 12, 2009 at 9:21 PM, Wouter van Ooijen <RemoveMEwouterTakeThisOuTspamvoti.nl> wrote:

{Quote hidden}

> -

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