>The j options in the MPC compiler are all unsupported options. There
>is no garantee that they will always remain.  There are put into the
>compiler for a number of reason's some for us to understand specific
>issues about code generation and some in response to requests from
>customers for a specific feature or option. I just checked the compiler
>sources and j7 is still there. The internal name is NoBSR and it was put
>into the compiler in response to Dana Raymonds request and it is used by
>us to establish an absolute limit as to the amount of optimization that
>can be done. (No BSR code generation but the rest of the generated code
>is the same)
>
>Walter

Hello Walter. Welcom to the PICLIST.

I didn't realize that you added that option on my request. It has come in
handy at times, as you can imagine. Yesterday I spent an hour trying to free
up a few paragraphs of code space to cram some diagnostics into a product
that just went into production. Unfortunately I couldn't use option j7.

I have to say Walter that MPC is a very good, professional grade product.
The problems can be overcome by someone willing to invest the learning time
(like myself). In my opinion It lacks only 2 things: Bugs needing repair;
and an optimization pass to remove redundant ram page selects from within
code blocks. That program I was working on filled a 16C84's code space (to
within 6 bytes) and yet MPC only gave 4 warnings when option j7 was used.

Thank you for your support over the years Walter.

Regards, Dana Frank Raymond
dfr@icom.ca