MCU mimicking a SPI flash slave - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: MCU mimicking a SPI flash slave
On Tuesday, June 20, 2017 at 11:44:39 AM UTC+3, David Brown wrote:
Quoted text here. Click to load it
a

No. If you don't know which datum of which size and type is you are
not up to programming. Delegating to the tool to track that means
only more work for the programmer, sometimes a lot more while tracking
what the tool got wrong _this_ time.

Quoted text here. Click to load it
,

If "counting" is too much of a workload is too much for a person he
is not in the right job as a programmer (hopefully "counting" is not
taken literally here, it means more "counting up to ten").
Delegating simple tasks to the tool makes life harder, not easier,
as I said above. Often a lot harder.

Controlled types, sizes etc. by the machine are meant for the user,
not for the programmer. They are supposed to make these work, this *is*
their job. Pretty much like a meal is supposed to be served nicely
arranged on a plate for the consumer; however for the cook the
ingredients are a lot more convenient in a raw form.

Dimiter

=========================
=========================
====
Dimiter Popoff, TGI             http://www.tgi-sci.com
=========================
=========================
====
http://www.flickr.com/photos/didi_tgi/


Re: MCU mimicking a SPI flash slave
On 20/06/17 10:36, dp wrote:
Quoted text here. Click to load it

Er. No.

David is suggesting, correctly IMNSHO, that sometimes
it is necessary for me to specify exactly what the
tool has to achieve - and then to let the tool do it
in any way it sees fit.

He gave a good example of that, which you snipped.

With types such as uint8_t, uint_fast8_t and uint_least8_t,
modern C is a significant advance over K&R C.



Quoted text here. Click to load it

I can only easily deal with three numbers: 0, 1, many :)
All other numbers are a pain in the ass and I'm more
than happy to delegate them to a tool.

Re: MCU mimicking a SPI flash slave
On 20.6.2017 ?. 13:25, Tom Gardner wrote:
Quoted text here. Click to load it

It may be an improvement in C indeed. But this is not relevant
to the main point: delegating simple tasks to the tool costs
the programmer more, often a lot more effort than it returns.

Quoted text here. Click to load it

Well you snipped my example with the programmer and the cook, let
me repost it:

Quoted text here. Click to load it

In the case you let the tool do all the cooking for you you
relegate yourself to the role of the waiter if not the consumer.
And if you have to do the job of the cook having kept yourself
fit only about the skill set of a waiter - it will cost you a
lot more time to do the job than it would cost you had you not
lef your cooking skills decay.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/





Re: MCU mimicking a SPI flash slave
On 20/06/17 11:49, Dimiter_Popoff wrote:
Quoted text here. Click to load it

For the examples given you haven't demonstrated your point,
and you have ignored the main point being made.

To repeat the main point being made: it is better for me
to specify (in the source code) what the tool has to achieve,
and let the compiler decide how to achieve it. It is worse
for me to /ambiguously/ specify (in the source code) what
is required, and to implicitly point to the compiler's man
pages - and probably to hope the next program maintainer uses
the correct compiler flags.



Quoted text here. Click to load it

I ignored it because, like most analogies, its
relevance is dubious and encourage focusing the
attention on /inapplicable/ details.

That has already started happening in another
response which has started to discuss menus/meals
that people had last week!

I beats me how that is supposed to illuminate
the benefits of stating the peripheral's structure
and letting a compiler sort out how best to generate
code for it.


Re: MCU mimicking a SPI flash slave
On 20.6.2017 ?. 14:54, Tom Gardner wrote:
Quoted text here. Click to load it

Oh I did make my point all right, check my first post on the thread.

The examples are completely beside my point, they are about C
specifics and sort of.

Quoted text here. Click to load it

Like it or not thinking is about making analogies. I realize
my point is probably doomed to never come across to the vast
majority of programmers today, sort of like trying to explain
colours to a blind person (absolutely no insult meant here, I
know I am talking to intelligent people, just wrestling to make
a point).
What I see from where I stand is that C as a language - not as
a compiler, toolchain quality etc. - costs a lot more work to
the programmer than needed. One of the reasons for that is the
fact that the programmer has to delegate to the toolchain a lot
of trivial "no brainer" work and _this_ costs a significant, at
times a prohibitive, effort. How do I make my point to people
who have never been really fluent in a lower level language
which does not have the ugliness of a poor underlying model etc...
A lost cause I guess.

Quoted text here. Click to load it

It is not supposed to illuminate that. It is supposed to demonstrate
that while wrestling with the compiler to make it do this or that
one can often waste a lot more time if he could omit this step.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/



Re: MCU mimicking a SPI flash slave
On 20/06/17 14:09, Dimiter_Popoff wrote:
Quoted text here. Click to load it

Yeah. Been there done that :(

Quoted text here. Click to load it

Oh, there we are in violent agreement about the end result!
Overall C/C++ has (arguably) become too complex for simple
things, and (unarguably IMNHSHO!) become too poorly
specified for complex things. Trying to be "all things
to all people" is rarely successful.

Nowadays C (and even more with C++) is part of the problem
rather than part of the solution. The abstractions, which
were a useful valid advance in K&R days, have become *very*
leaky over the years with the advance of technology. Hells
teeth, it is only recently that C/C++ has recognised the
need for a memory model to deal with all the subtle behaviour
in SMP and NUMA machines. I reserve judgement on whether it
will be a success; even starting from a clean slate Java had
to revise its memory model!



Re: MCU mimicking a SPI flash slave
On 20/06/17 15:24, Tom Gardner wrote:
Quoted text here. Click to load it

Examples I've come across include such gems as...

"However, many C compilers use non-standard expression
grammar where ?: is designated higher precedence than =,
which parses that expression as
e = ( ((a < d) ? (a++) : a) = d ), which then fails to
compile due to semantic constraints: ?: is never lvalue
and = requires a modifiable lvalue on the left. Note
that this is different in C++, where the conditional
operator has the same precedence as assignment."
http://en.cppreference.com/w/c/language/operator_precedence

"i = ++i + 1; // undefined behavior[in C] (well-defined in C++11)"
http://en.cppreference.com/w/cpp/language/eval_order

The ability to break a compiler's legitimate optimisations
by "casting away constness and volatility" (IIRC that took
several years of committee deliberation as to whether
it was required or forbidden behaviour!)

And of course, the amusing C++ FQA.

All of which makes the simplicity of Forth seem appealing :)

Re: MCU mimicking a SPI flash slave
On 20/06/17 18:46, Tom Gardner wrote:
Quoted text here. Click to load it

Neither C nor C++ is a problem here.  People writing absurd obfuscated  
nonsense in their code may be a problem, but that applies in any language.


Quoted text here. Click to load it

"casting away constness and volatility" means writing code that  
explicitly tells the compiler "I know better than you do here, and I  
know it is safe to break rules about the code".  Either that is true,  
and it lets you write the code you want, or it is wrong and you've made  
a mistake - as you can do in all languages.

Quoted text here. Click to load it

Have you read it?  It is mostly misunderstandings, repetitions, outdated  
information, or completely unrealistic code.  There are a few good  
points in it, but you have to work hard to find them.

Quoted text here. Click to load it

C is mostly simple and clear (if well written).  C++ is a much bigger  
and more complex language - it has greater scope for writing good code,  
but also greater scope for making a mess.  Simplicity of a language is  
not necessarily a good thing any more than complexity is - you don't get  
much simpler than a Turing machine, but I would not want to use it for  
application programming!


Re: MCU mimicking a SPI flash slave
On 20/06/17 21:28, David Brown wrote:
Quoted text here. Click to load it

Agreed, but the differences between the two languages is a
big hint that there are surprising and unnecessary dragons
lurking to catch people that haven't spent several decades
following the differences and /newly introduced/ pitfalls.

Do you have any comment about the previous point about
/some/ compilers apparently /choosing/ non-standard
expression grammars? That seems remarkable to me.


Quoted text here. Click to load it

That is problematic when a library is compiled and optimised
assuming that the const statements are correct, and later on
someone else in a different company uses that library in a
way which violates those assumptions.

In those circumstances the user probably doesn't know better.


Quoted text here. Click to load it

Indeed. But not all of the points can be "wished away"; many
a truth is spoken in jest.


Quoted text here. Click to load it

I completely agree :)

The major problem with C/C++ is that it can't make up its
mind whether it wants to be simple low-level and near to
the silicon, or an expressive high-level general purpose
applications language. Either would be valid, but in
trying to be both it misses both targets.

Fortunately the marketplace has decided that in most cases
C/C++ isn't "the best" general purpose application language;
Java, Python and similar are the future there.

Re: MCU mimicking a SPI flash slave
On 21/06/17 01:58, Tom Gardner wrote:
Quoted text here. Click to load it

What pitfalls?  Everyone who has ever been involved in C (or C++) knows
that expressions like "i = ++i + 1;" are classic examples of undefined
or unspecified behaviour.  There is never a reason for writing such
things in code, and it is always unclear to the reader (even in later
C++ standards where some cases now have defined ordering).  Just don't
write such silly code - problem solved.

Later C++ standards some such cases defined behaviour - that does not
affect C, or introduce new pitfalls to either C or C++.  At most, it
makes previously undefined code into defined code - that will either fix
the broken code or leave it broken.  It will not break code that was
previously working.

If you are interested, the reason why these things are now defined in
C++ is not because anyone would ever /want/ to write "i = i++ + ++i;".
It is merely a side-effect of making certain other orders defined, where
they /are/ useful.  In particular, people have assumed that expressions
like "cout << ++i << ++i;" are fully defined - in fact their orders were
not.  But compilers helpfully /did/ follow the order that programmers
expected, and the standards have merely been updated to codify existing
practice.


Quoted text here. Click to load it

As far as I can see, the difference for C is merely which error message
the compiler will give depending on the way it interprets the
expression.  If it follows the C grammar rules for how a mixture of ?
and = is to be interpreted, the result cannot be parsed and is therefore
an error.  If it follows the C++ grammar rules (which is the
non-standard C compiler behaviour mentioned), the result can be parsed
but is a constraint violation (a bit like writing "5 = a;"), and is
therefore an error.

I don't see a significant practical difference here.

(There are plenty of other cases where some C compilers get the details
of the standards wrong - but unless you are talking about really poor
quality compilers, these will very rarely be seen in real-world code.)

Quoted text here. Click to load it

No, I cannot see any problem here.

If a library exports some constant data, then it is absolutely fine that
the library is compiled and optimised on the assumption that the data
never changes.  If user code casts away constness and tried to change
that data, the user code is clearly wrong.  It is wrong in the same way
that code passing -1 to a square root function is wrong, or code that
calls a sin() function but is expecting to get the results of cos().

Quoted text here. Click to load it

If the user does not know that he should not be changing data that is
specified to be constant, then the user is not qualified for the job as
programmer.

Quoted text here. Click to load it

The FQA is not particularly funny or truthful.  (I have read it, as well
as the original C++ FAQ - have you?).

C++ certainly has plenty of flaws - it is a /big/ language.  Some of
these flaws get fixed over time in newer standards, others remain, and
yet more get introduced.  And of course there is plenty that is a matter
of taste or style.  But wild exaggeration of the problems is no more
helpful than any claim that the language is perfect.

<https://gist.github.com/klmr/5423873


Quoted text here. Click to load it

One of the major problems with C/C++ is that there is no such language -
but a lot of people seem to think there is.


A lot of people find C++ works fine for one or both targets.  It is, I
think, the only language that covers such a wide range.  But it is not a
/simple/ low-level language - it is a big language, whether you use it
for low-level tasks or high-level tasks.

There is, however, no need to use /all/ of C++.  If you are writing PC
code, you will use the standard library a lot - you will use containers,
strings, etc.  But you don't use them on low-level code.  Different
parts of C++ are better suited for different needs.

C, on the other hand, is not well suited for higher level work at all.
There was a time when it was one of the better choices, because there
were so few alternatives.  But not now.

Quoted text here. Click to load it

Most of my embedded programming is in C, with a small (but increasing)
part C++.  Most of my PC programming is in Python.



Re: MCU mimicking a SPI flash slave
On 20/06/17 15:09, Dimiter_Popoff wrote:

<snip>

Quoted text here. Click to load it

You have given absolutely /no/ indication in the slightest as to why
that might be the case, or why you might think so.  What do you mean by
this?  Can you give examples?

Quoted text here. Click to load it

Again, this makes no sense and is contrary to common experience.  What
makes you think that it is more productive for the programmer to do
trivial no-brainer work than to let the tools do it?

Quoted text here. Click to load it

I have programmed in assembly for a dozen or more architectures - when I
started my job, it was the language of choice for small
microcontrollers.  In fact, when I learned assembly, I even had to hand
assembly the instructions to machine code on paper.

So assume that I am fluent in low level languages, and try to explain.
I think the real challenge lies in that you don't really know how C
works or how it is used.  (As with your posts, this is not an insult in
any way.)




Re: MCU mimicking a SPI flash slave
On 20/06/17 12:25, Tom Gardner wrote:

Quoted text here. Click to load it

There are three sorts of people in this world - those that can count,
and those that can't.


Re: MCU mimicking a SPI flash slave
On 20/06/17 11:36, dp wrote:
Quoted text here. Click to load it

The reason I know exactly which size a datum is, is because the type has
a fixed size!

If I need to know that "x" has 32 bits, I make sure of that fact by
declaring "x" as a "uint32_t" or "int32_t" in C.  I can do that,
precisely because C supports such hard coded data sizes.

In a language like Forth, or pre-C99 C, you can't do that portably.  An
"int" might be 16-bit, or maybe 32-bit, or maybe something weird - the
same applies to a Forth "cell".  You need pre-processor directives,
conditional compilation, implementation-specific code, etc., in order to
know for sure what sizes you are using.

Quoted text here. Click to load it

Are you seriously suggesting that sometimes compilers will get the sizes
wrong?  That if I ask a C compiler for an "int64_t", sometimes it will
give me a different size?

Or are you talking about more complex types?  If I define a struct that
I know should match an external definition (hardware registers, telegram
format, etc.) of a particular size, I can write:

typedef struct {
    uint16_t x;
    uint8_t ys[6];
    ...
} reg_t;
static_assert(sizeof(reg_t) == 24, "Checking size of reg_t struct");

The /compiler/ does the counting and the checking.  It does so easily
and reliably, handles long and complicated structures, is portable
across processors of difference sizes, and will always give a clear and
unmistakeably compile-time error message if there is a problem.

Quoted text here. Click to load it

You said it above - but you were wrong (IMHO).

Quoted text here. Click to load it

Think of having the compiler check sizes and do "counting" as like the
thermostat and timer on the oven.  The cook (or programmer) decides on
the temperature and timing he wants, but the oven handles the boring bit
of turning the elements on and off to get the right temperature, and
warns the cook when the timer is done.

Quoted text here. Click to load it


Re: MCU mimicking a SPI flash slave
On 20.6.2017 ?. 13:57, David Brown wrote:
Quoted text here. Click to load it

So C has improved. But this is only about C overcoming one of its
shortcomings by adding more complexity for the programmer to deal
with, which is exactly my point. You need to know what your compiler
does with your data type only if you have to rely on it to deal with
it instead of just dealing with it yourself when you know what it
is anyway.

Quoted text here. Click to load it

Are you seriously suggesting that you have not spent well over half
of your programming time figuring out what the compiler expects from
you.

Quoted text here. Click to load it

Then a month later the menu changes and you have to set the temperature
to the one for the meal you did last month. Oops, what was it?
Spend another week rediscovering that.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/


Re: MCU mimicking a SPI flash slave
On 20/06/17 13:19, Dimiter_Popoff wrote:
Quoted text here. Click to load it

We are talking about a change in the language nearly 20 years ago...

And even before that, it was normal to have a header with things like:

typedef short int i16;
typedef unsigned long int u32;

etc.

Pre C99, you had to make such headers yourself, adapt them to fit a
given implementation, and there was no standardisation of the names.
But it was a job you did once for each platform you used.  Because C is
a typed language, you can make the definitions of the types depend on
the platform, but the code using the types is then platform independent.

Quoted text here. Click to load it

/Where/ is this complexity you talk about?  I cannot understand what you
mean here, and why you think there is some extra effort.  If I want a
32-bit variable, I make an int32_t or a uint32_t (signed or unsigned).
I make the choice of the characteristics I need for the data, and write
it clearly, simply, and quickly in the source code.  There is no effort
involved.

Quoted text here. Click to load it

That makes no sense whatsoever.  How do you "deal with it yourself"?
You write source code, the compiler compiles it to machine code.  You
are relying on the compiler, just like when you write in assembly code
you rely on the assembler.

You can get a difference when you don't care about the details.  If I
write "x * 5", I (usually) don't care if the compiler implements that
with a multiply instruction, or shift and add instructions, or a "load
effective address" instruction with odd addressing modes, or if it has
figured out that "x" is always 3 at this point in the code, and can use
15 directly.

And when I /do/ care about the details, such as the size of a piece of
data, /then/ I write explicitly what I want.  That, if anything, is
"dealing with it myself".

Quoted text here. Click to load it

The compiler expects me to write valid C code.  Nothing more, nothing
less.  I have spent time learning how to write valid C code - but no,
that has not taken half my programming career.

Quoted text here. Click to load it

What on earth does that mean?  When a cook sets the temperature on his
oven thermostat, that does not somehow suck the information out his
brain and erase it from all his recipe books!




Re: MCU mimicking a SPI flash slave
Quoted text here. Click to load it

Why would that be?  I can see that it's far better for programmers who
don't test their programs, but what is the advantage for programmers
who test their programs?

Quoted text here. Click to load it

And I would especially hate it if an IDE is distracting me by nagging
me about minor details while I am focusing on something else.

Quoted text here. Click to load it

If the language does not require the 64-bit types, you can hardly
claim them as a language feature.

Anyway, if 64-bit integers were needed on 16-bit-cell systems, we
would add them to Forth.  But in discussions about this subject, the
consensus emerged that we do not need them (at least not for
computations).

By contrast, Gforth and PFE have provided 128-bit integers on 64-bit
systems since 1995, something that C compilers have not supported for
quite a while after that.  And once GCC started supporting it, it was
quite buggy; I guess the static-checking-encouraged lack of testing
was at work here.

Quoted text here. Click to load it

There is a difference between "it is possible" and "it happens".  My
experience is that, in C, if you have tested a program only on 32-bit
systems, it will likely not work on 64-bit systems; in Forth, it
likely will.

Quoted text here. Click to load it

Tough luck.  Why would I need a double FLOOR5 on a 16-bit platform?

- anton
--  
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 20/06/17 14:12, Anton Ertl wrote:
Quoted text here. Click to load it

Honestly?  You can't see the advantage of spotting errors at as early a
stage as possible?

Why would someone bother writing test patterns to catch possible errors
that the tools can see automatically?  That is just a waste of
everyone's time, and it's easy to forget some tests.

Errors of various sorts can happen when you write code.  They can be
everything from misunderstandings of the specifications, to small typos,
to stylistic errors (which don't affect the running code, but can affect
maintainability and lead to higher risk of errors in the future), to
unwarranted assumptions about how the code is used.  Producing a correct
program involves a range of methods for avoiding errors, or detecting
them as early as possible.  Testing (of many different kinds) is /part/
of that - but it is most certainly not sufficient.  It is /always/
cheaper and more productive to spot errors at an earlier stage than at a
later stage - and detecting them at compilation time is earlier than
detecting them at unit test time or system test time.


Quoted text here. Click to load it

Incorrect code is not a minor detail.

Quoted text here. Click to load it

C /does/ require them (in C99), and they /are/ a language feature.
(Technically, C requires an integer type that is at least 64 bits, but
for most practical purposes, real implementations have exactly 64-bit
types.)  There are C compilers that don't support all of C99.

And I have used 64-bit integers on an 8-bit microcontroller.  It is a
rare requirement, certainly, but not inconceivable.

Quoted text here. Click to load it

Static checking is an addition to testing, not an alternative.

Quoted text here. Click to load it

I don't see a way to write portable code that works with known sizes of
data in Forth.  All I have seen so far is that you can use single cells
for 16-bit data, and double cells for 32-bit data.  This means if you
want to use 32-bit values, your choice is between broken code on 16-bit
systems or inefficient code on 32-bit systems.  (And you can only tell
if it is broken on 16-bit systems if you have remembered to include a
test case with larger data values.)

I work on embedded systems.  I need to be able to access memory with
/specific/ sizes.  I need to be able to make structures with /specific/
sizes.

Can you show me how this is possible in Forth, in a clear, simple and
portable manner?

Quoted text here. Click to load it

That is not for you to worry about.  Think of me as a customer asking
for a piece of code written in Forth.  I want a FLOOR5 function that
handles 32-bit values, works correctly on 16-bit and 32-bit cell
systems, and is efficient on both sizes of system.  Can it be done?



Re: MCU mimicking a SPI flash slave
On 20/06/2017 15:48, David Brown wrote:
Quoted text here. Click to load it

Yes, but you may not like it - use conditional compilation

0 invert 65535 u> [if]
: floor5 ( n1 -- n2 ) 1- 5 max ;       \ 32 bit cells
[else]
: floor5 ( d1 -- d2 ) 1. d- 5. dmax ;  \ 16 bit cells
[then]

--  
Gerry

Re: MCU mimicking a SPI flash slave
On 20/06/17 22:16, Gerry Jackson wrote:
Quoted text here. Click to load it

Conditional compilation is fine as a solution.  But supposing you wanted  
a number of functions that were all 32-bit (let's say, floor6, floor7,  
and floor8 due to a lack of imagination).  Is there any way to have a  
single conditional bit, and then use the features in other words?  (Like  
defining the type "int32_t" once in C, and using it thereafter.)  My  
stab at a solution would be:

0 invert 65535 u> [if]            \ 32 bit cells
: -32 ( n1, n2 -- n3 ) - ;
: max32 ( n1, n2 -- n3) max ;
: to32 ( n1 -- n1 ) ;
[else]                    \ 16 bit cells
: -32 ( d1, d2 -- d3 ) d- ;
: max32 ( d1, d2 -- d3) dmax ;
: to32 ( n1 -- d1 ) S>D ;
[then]


: floor5 ( 32x1 -- 32x2 ) 1 to32 -32 5 to32 max32 ;
: floor6 ( 32x1 -- 32x2 ) 1 to32 -32 6 to32 max32 ;
etc.



The equivalent C (without the C99 sized integers) is:

#include <limits.h>

#if UINT_MAX == 65535
typedef long int i32;
#else
typedef int i32;
#endif

i32 floor5(32 v) {
  return (v < 6) ? 5 : (v - 1);
}

i32 floor6(32 v) {
  return (v < 7) ? 6 : (v - 1);
}


(That is, like your Forth, assuming that you either have 16-bit cells /  
ints and 32-bit double cells / long ints, or 32-bit cells / ints.)








Re: MCU mimicking a SPI flash slave
On 20/06/2017 22:15, David Brown wrote:
Quoted text here. Click to load it

Yes that's a way to achieve it. However, for performance, I would use  
POSTPONE and IMMEDIATE to compile the small functions inline e.g.

0 invert 65535 u> [if]            \ 32 bit cells
: -32 ( n1, n2 -- n3 ) postpone - ; immediate
: max32 ( n1, n2 -- n3) postpone max ; immediate
: to32 ( n1 -- n1 ) ; immediate
[else]                    \ 16 bit cells
: -32 ( d1, d2 -- d3 ) postpone d- ; immediate
: max32 ( d1, d2 -- d3) postpone dmax ; immediate
: to32 ( n1 -- d1 ) postpone S>D ; immediate
[then]

Then, for example, TO32 for 32 bit cells compiles nothing in FLOOR5 etc.

But, as an aside, a warning, -32 is treated by Forth as an integer so  
after the above definitions you couldn't ever use -32 as a literal in  
another definition as it would compile a -. Better to call it, say,  SUB32

With this technique you could also do:

0 invert 65535 u> constant 32bits
: -32 32bits if postpone - else postpone d- then ; immediate

and so on. This would result in the same compiled code for FLOOR5 etc  
with less source code noise. At the cost of more compiled code of course  
as -32 etc are bigger. But this wouldn't matter if you were cross  
compiling on a host for a target system.

Another alternative is to factor out the conditional part:

0 invert 65535 u> constant 32bits
: postpone-it  ( xt1 xt2 -- ) \ xt1 is for 32 bit cells, xt2 for 16 bits
    32bits if drop else nip then compile,
;

: -32  ['] - ['] d- postpone-it ; immediate
: max32 ['] max ['] dmax postpone-it ; immediate
etc

but whether that is worthwhile depends on how many of these definitions  
there are.


--  
Gerry

Site Timeline