Microchip & OnSemi want to buy Atmel?

[Ulf Samuelsson]

Would people require a 64 bit timer on a 64 bit machine?

I.E.: The width of the datapath has nothing to do with the width of
timers...

You only need 32 bit timers when you have very slow events
or need very high resolution AND long times.
At 100 MHz, the timer will wrap around after 655 us.
Would be interesting with an example where this is an issue.

The peripheral development is driven by market needs,
so enough people will have to be vocal for a change to happen.

Seriously, perhaps they've got a 16-bit timer design laying around,
and they're too lazy, or time-to-market's too short, to design in a
32-bit timer?

Also, it could be the sort of thing Freescale (this isn't an ad,
I've just been using their parts lately and saw all this on the
website) is doing with its new line of "8-bit and 32-bit compatible
microcontrollers." It appears what they've done is made certain
versions of 32-bit-core microcontrollers that have the exact same
on-chip peripherals as some models with 8-bit cores. Thus if you
design in the 8-bit controller and then find out it doesn't have
enough horsepower, you can "drop in" the 32-bit part (more expensive,
but I think pin-compatible) and just recompile your C code for the
32-bit target.
I'm not sure if or how useful all that would be, but as the 8-bit
parts tend to have 16-bit timers, the equivalent 32-bit parts would
also have those same 16-bit timers.

--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[Frank Buss]

Would people require a 64 bit timer on a 64 bit machine?

I.E.: The width of the datapath has nothing to do with the width of
timers...

You only need 32 bit timers when you have very slow events
or need very high resolution AND long times.
At 100 MHz, the timer will wrap around after 655 us.
Would be interesting with an example where this is an issue.

I think you are right and this is no problem, you can implement it in
software. E.g. if you need a PWM signal of some ms, most of the time you
don't need 1 us resolution, which makes it even easier to write it in
software.

BTW: what do you think of the SEAforth 40C18?

http://www.intellasys.net/index.php?option=com_content&task=view&id=60&Itemid=75

There are 40 cores and a interesting idea is that you can implement your
own IO function in firmware, like SPI, I2C, CAN etc. Sounds like a good
idea, because you'll get all protocols you want. E.g. sometimes there are
nice microcontrollers, but you need CAN, which is not provided. With a
concept where you can implement it in firmware, all protocols are possible
(but maybe not very fast ones, like ethernet or USB).

And using non-clocked, asynchronous concepts sounds interesting, too. I
guess they are using something like dual-rail signalling or the Muller C
gate:

http://brej.org/papers/s2a.pdf
http://www.eetimes.com/editorial/2000/coverstory0005.html

This would help for EMI, too.

 

[Ulf Samuelsson]

Some might
- but the jump from 32 to 64 is much less practically usefull, than from
16 to 32.



Of course not, but it has a LOT do do with precision, and dynamic range.
If you can calculate in 32 bit numbers, why feed that with
an UPPER limit of 16 bit granularity ?


Timers also Capture, and generate.


Precision frequency generation, and precision frequency measurement
are two examples. Your example has you stuck at >1.52KHz, or
if you prescale, you lose step size.

I can handle precision frequency measurement by running an interrupt
at mid level of the timer, which checks if something has triggered or not
and this will give me the same precision.
I can set up compare registers which toggle at a specific time
with the same precision as a 32 bit timer.
The 32 bit timer will simplify some S/W, I'd admit to that,
but it is really not neccessary.

With 16 bits timers, you hit a 16 bit quantize limit, on any PWM DAC

This is only a problem, if you run the PWM at less than 2 kHz.
I doubt the "DAC" will work as expected in this case.

design, but 18-20-24 bit ADCs are common.
With 100MHz/32Bits, you can deliver 18 bits at 380Hz, and 20 bits at
95Hz.

If you want to have a 24 bit DAC; using a single slope ADC,
you can again take an interrupt every 655 us, and figure out
in which frame the capture register triggered.

Or, you may have a LVDT type problem, that needs precise phase measurement
at 400Hz - suddenly, a 32 bit timer, delivers 4x the
performance.

No, you interrupt every 655 us, and update the upper 16 bits in an SRAM
location.
You can do 32 bit PWM and 32 bit capture in S/W, and it is not that hard,
because once the 32 bit is needed, then you got plenty of time.

Try doing a reciprocal frequency counter with 16 bit peripherals....
100MHz can give you 8 digits/second, or ~27 bits

What you want is to be able to have the system granularity, under
the noise floor.

Quadrature counters are also a natural for 32 bits, rather than 16 bits.

If you look at stepper motors, then you have ~200 steps per revolution.
Why do you need much higher granularity?

Plently of examples, you just need to look around....

TI have some nice features, where they get precisions above the
clock frequency on some of their DSP peripherals.

Many of the ATtinys have a PLL allowing you to run timers at higher speed
than the core. So does the XMEGA.
Timers can run at 128 MHz and the event system will allow you
to expand timers to 32/48 bits etc..

..and the designers need to also think about how these might be used.

It is already happening, 32 bit timers are becoming more
common. The newest NXP parts also have 32 bit Quad counters,
with velocity features.

Yes, all other things alike, you would rather have a 32 bit timer,
instead of a 16 bit timer, with S/W for the upper part.
If you have a 10 Mu application, you would not pay much
more for a 32 bit timer, if you can live with a 16 bit timer.

-jg

--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[David Brown]

C is lower level than Pascal, it wins there. Generally high level
languages are good for newcomers (like tourists who use a phrase
book while on a trip), but for real work one needs lower level
(that is, if you will write a novel you better learn the language
beyond the phrase book).

That's a very popular misunderstanding. Pascal has higher level
concepts than C, but it has everything necessary for low-level
programming. Just like C, compilers need extra support for things like
interrupts, but otherwise it's complete - just like Ada. There is no
particular reason for a given program to be smaller and faster (target
code) in C than in Pascal, nor is there any reason to think a processor
architecture is suited to C but not Pascal (or vice versa).

In fact, for 8-bit processors, you would expect Pascal compilers to be
better - after all, they have native support for 8-bit arithmetic
without any of this "promotion to int" nonsense.

C became popular because of Unix. Since then, the main reason C is the
most heavily used low-level language is because it is the most heavily
used low-level language.

 

[CBFalconer]

It sounds like you haven't ever actually used Pascal, but rather
some kind of non-standard extended Pascal. In you're going to
claim that Pascal is useful for low-level programming, please
explain how to efficiently perform common low-level tasks, such
as to set bit 5 of a 16-bit integer (assuming that bit 0 is the
LSB), or to compute the logical AND of two 16-bit integers.

I have used ISO standard (level 0) Pascal for almost everything.
You need to stop thinking about setting bits, etc., and think about
the operations. I think you will find that sets do a more than
adequate job.

Don't forget that the 'non-standard extended Pascal' you refer to
is probably from Borland, and that none of their products even meet
the requirements of the Pascal standard. This is one of the major
crosses Pascal has had to bear.

 

[Cesar Rabak]

CBFalconer escreveu:

I have used ISO standard (level 0) Pascal for almost everything.
You need to stop thinking about setting bits, etc., and think about
the operations. I think you will find that sets do a more than
adequate job.

How would it be in [ISO level 0] Pascal the equivalent operation of
clearing the Timer 1 Interrupt Flag of garden variety PIC?

 

[CBFalconer]

.... snip ...

I've used UCSD Pascal, Turbo Pascal, and Apple MPW Pascal, and
several other non-standard Pascal dialects to do this kind of
stuff in the past, but that has nothing to do with whether the
Pascal language is suited to it.

Scud came close, Turbo failed, and I don't know about Apple, to
meeting the ISO standard. Scud failed in other respects IMO. I
started in 1975 or 6 with the P4 compiler, developed it into a full
standard complying system (the standard was developing at the same
time) which ran on micros or main-frames. My systems could
generate either P-code for interpreters or machine code for the
machines. Apart from some horrible accidents almost 10 years ago
(lost everything) it would be public domain now.

 

[David Brown]

It's only useful as a "real working language" for a somewhat limited
problem domain, because of the limitations of the language definition.
The various non-standard extensions address those limitations, but when
you're using them you aren't really programming in Pascal.

When I program embedded microcontrollers in C, I use extensions for
interrupt handling, inline assembly, flash data (on Harvard architecture
micros), and other target-specific features. Does that mean that I'm
not programming in C, or that C is not suitable for low-level
programming because the standards don't include such features? Can you
give me an example of *any* programming language where existing
compilers slavishly follow the language's standards, implementing
everything and adding nothing? Real-life, non-academic programming is
done using a mixture standards language and implemented language.

I agree that the lack of bitwise operators in the standards is an issue
for programming (not just low-level stuff, but it's perhaps more
immediately obvious there) - I hadn't noticed the lack because practical
Pascal systems support it.

If you are going to asser that the Pascal language was *designed* to
be useful as a real working language, I'd very much like to see an
authoritative reference supporting that claim.

I don't have any history books on hand. But Niklaus Wirth developed a
fair number of programming languages - they were not made just for fun,
even though their success in large-scale usage varies.

 

[Jasen Betts]

That's a very popular misunderstanding. Pascal has higher level
concepts than C,

it has strings, and what else? "with"

can it create arrays of a size determined at run-time? (can it?)
haw about variadic functions (I don't think it has them)

but it has everything necessary for low-level programming.

uudecode is a relatively low-level process,
for every 4 pack the least significant 6 bits of each toegther to make
3 bytes, how would you write that in pascal.

(I can see two ways to do it in C, one of them exposes no arithmetic
but is non-portable but that could probably be solved with a #define
if portability is an issue)

Just like C, compilers need extra support for things like
interrupts, but otherwise it's complete - just like Ada. There is no
particular reason for a given program to be smaller and faster (target
code) in C than in Pascal, nor is there any reason to think a processor
architecture is suited to C but not Pascal (or vice versa).

well for the most part that's true, the few things that are more useful
for pascal or more useful for C aren't extremely exciting or a great
hardship if they aren't available.

In fact, for 8-bit processors, you would expect Pascal compilers to be
better - after all, they have native support for 8-bit arithmetic
without any of this "promotion to int" nonsense.

I've not looked closely at this, but I think for most 8-bit expressions
things can be written to use only 8 bits

C became popular because of Unix. Since then, the main reason C is the
most heavily used low-level language is because it is the most heavily
used low-level language.

ms-dos has signs of being written in pascal, why didn't pascal take off?

Bye.
Jasen

 

[Ulf Samuelsson]

32 bit PWM with a 16 bit timer.
CompareC = Top. reaching Top will reset counter to 0.
CompareA = Toggle

Case 1:
Period is less than 65536 cycles: Obvious implementation

Case 2:
Period is 65537 cycles. Dutycycle = 1
Set CompareC to 32768
Set CompareA to 1 & Toggle I/O
Interrupt on Compare A
Set CompareA to not toggle I/O
Interrupt on CompareC (reset counter)
Set CompareC to 32769.
Interrupt on CompareA
Set CompareA to toggle.

Case 3:
Period is 65537 cycles. Dutycycle = 65536
Set CompareC to 32768
Set CompareA to not toggle I/O
Interrupt on CompareC
Set CompareC to 32769
Set CompareA to 32768 & Toggle I/O
Interrupt on CompareC
Set CompareC to 32768
Set CompareA to not toggle I/O
etc.

Case 4:
Period is 65537 cycles. Dutycycle = 32768
Set CompareC to 16384
etc...

Have you actually tried doing this ?

As soon as you expand a capture system with SW, you have serious
aperture problems. There is a window between the HW register, and SW
register, where they are out of sync. You also have TWO interrupts
racing, one on the capture edge, and another trying to keep the MSB up to
date.

Interrupt on Timer wraparound (Higher Interrupt priority than Capture)
Timer = Timer + 1

Interrupt on Capture
Capture[15:0] = H/W Timer
Capture[31:16] = S/W Timer

If you cannot prioritize interrupts, then there would be a problem.

That simply does not happen with a 32 bit capture, and the better
timers are adding small fifos on capture. That allows narrow pulses
to be easily handled.


Microstepping, and shock effects on encoders are a couple of reasons.

Your replies illustrate the classic blinkered thinking of some
chip-designers.
The key is how someone COULD use the system for a better design, not how
many band-aids can be stacked to make it sort-of work

I've done many CPLD designs, to extend/fix shortcomings in peripherals
- those blindspots are things the chip designers SHOULD be chasing down.
On 32 bit uC, the excuses have gone

They are, but it is done according to priority, and nitty gritty details
tend to get less attention than adding complete blocks.
The XMEGA project was a result of collecting customer feedback
for several years and I think the result is quite good.

Timers tend to be 'not sexy' and so the evolution rate is slow...

True, I do hamper a lot about timers internally...
Keep a presentation on what to improve on peripherals which
I provide to the MCU product lines.
This is now ~150 pages, and a significant part is on timers.

The AT90PWM circuits will add 4 bit of resolution to the timer
which runs from a 64 MHz PLL.

Do you mean Xmega timers can run to 128MHz ? - which data sheet shows that
?

Look in the Users Manual.

Can I do a no-aperture-error, 32 bit capture, from a 100MHz clocked timer
?

The XMEGA has an event system, that will allow you to generate a 32 bit
timer.
The upper 16 bit timer will be clocked by an event coming from the lower 16
bit timer.
IIRC, The hispeed will work in PWM mode only, but you can use the timer as a
32 bit
Capture timer at 32 MHz.

The Xmega have nice peripherals, is there a AVR32 with the same
peripherals ? (or will the new cortex devices use some of the xmega ideas
?)

The XMEGA does not have the AMBA bus, but Atmel has already
said that the UC3C will use some of the ideas from XMEGA.
The contents of other circuits are yet to be revealed.

I do like the better peripherals in the NXP Cortex releases.

Challenges are always nice!

-jg

--
--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[Daniel Rudy]

At about the time of 10/13/2008 4:15 AM, David Brown stated the following:

That's a very popular misunderstanding. Pascal has higher level
concepts than C, but it has everything necessary for low-level
programming. Just like C, compilers need extra support for things like
interrupts, but otherwise it's complete - just like Ada. There is no
particular reason for a given program to be smaller and faster (target
code) in C than in Pascal, nor is there any reason to think a processor
architecture is suited to C but not Pascal (or vice versa).

I'm a Pascal to C convert. I have to admit, C does have its strong
points over Pascal, but it is also quite easy to...how shall I put
this...totally ****** something up if you are not paying attention. At
least in Pascal, if you tried to do something weird, the compiler would
flip you the finger. A C compiler just assumes that you know what you
are doing. I have found in some cases, it assumes wrong and you won't
know it until your program blows up. With all the different compilers
out there, I have found that gcc holds its own quite well. And unless
you are programming for Microsoft, gcc is one of the defacto standard
compilers out there.

In fact, for 8-bit processors, you would expect Pascal compilers to be
better - after all, they have native support for 8-bit arithmetic
without any of this "promotion to int" nonsense.

C became popular because of Unix. Since then, the main reason C is the
most heavily used low-level language is because it is the most heavily
used low-level language.

I've been programming in C for Unix for some time now. I have looked at
Unix kernel code. Most of it is written in C. Although there's a few
pieces that are written in assembly for the particular platform that it
is targeted for. It is mainly for direct processor control to perform
tasks that would be very difficult if not impossible to code in C.
Direct register access comes to mind.

Japanese is alphabetized. There are in fact *TWO* alphabets (They call
them kanna), and the Chinese characters that they ripped off are called
Kanji. The problem is that all three are interdispersed in the writing.

 

[Ulf Samuelsson]

I think the following should do it:

U16 TimerHigh;

union {
struct {
U16 low;
U16 high;
} x;
U32 timer;
} event;

interrupt Capture(void)
{
event.x.low = TIMER.CAPTURE;
event.x.high = TimerHigh;
if(event.low & 0x8000) { // Capture occured under second half of period
if((TIMER.COUNTER & 0x8000) == 0) {
// Timer interrupt has occured
event.high = TimerHigh - 1;
}
}
}

interrupt WrapAround(void)
{
TimerHigh++;
}



--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

32 bit PWM with a 16 bit timer.
CompareC = Top. reaching Top will reset counter to 0.
CompareA = Toggle

Case 1:
Period is less than 65536 cycles: Obvious implementation

Case 2:
Period is 65537 cycles. Dutycycle = 1
Set CompareC to 32768
Set CompareA to 1 & Toggle I/O
Interrupt on Compare A
Set CompareA to not toggle I/O
Interrupt on CompareC (reset counter)
Set CompareC to 32769.
Interrupt on CompareA
Set CompareA to toggle.

Case 3:
Period is 65537 cycles. Dutycycle = 65536
Set CompareC to 32768
Set CompareA to not toggle I/O
Interrupt on CompareC
Set CompareC to 32769
Set CompareA to 32768 & Toggle I/O
Interrupt on CompareC
Set CompareC to 32768
Set CompareA to not toggle I/O
etc.

Case 4:
Period is 65537 cycles. Dutycycle = 32768
Set CompareC to 16384
etc...

Have you actually tried doing this ?

As soon as you expand a capture system with SW, you have serious
aperture problems. There is a window between the HW register, and SW
register, where they are out of sync. You also have TWO interrupts
racing, one on the capture edge, and another trying to keep the MSB up to
date.

Interrupt on Timer wraparound (Higher Interrupt priority than Capture)
Timer = Timer + 1

Interrupt on Capture
Capture[15:0] = H/W Timer
Capture[31:16] = S/W Timer

If you cannot prioritize interrupts, then there would be a problem.

That simply does not happen with a 32 bit capture, and the better
timers are adding small fifos on capture. That allows narrow pulses
to be easily handled.


Microstepping, and shock effects on encoders are a couple of reasons.

Your replies illustrate the classic blinkered thinking of some
chip-designers.
The key is how someone COULD use the system for a better design, not how
many band-aids can be stacked to make it sort-of work

I've done many CPLD designs, to extend/fix shortcomings in peripherals
- those blindspots are things the chip designers SHOULD be chasing down.
On 32 bit uC, the excuses have gone

They are, but it is done according to priority, and nitty gritty details
tend to get less attention than adding complete blocks.
The XMEGA project was a result of collecting customer feedback
for several years and I think the result is quite good.

Timers tend to be 'not sexy' and so the evolution rate is slow...

True, I do hamper a lot about timers internally...
Keep a presentation on what to improve on peripherals which
I provide to the MCU product lines.
This is now ~150 pages, and a significant part is on timers.

The AT90PWM circuits will add 4 bit of resolution to the timer
which runs from a 64 MHz PLL.

Do you mean Xmega timers can run to 128MHz ? - which data sheet shows
that
?

Look in the Users Manual.

Can I do a no-aperture-error, 32 bit capture, from a 100MHz clocked timer
?

The XMEGA has an event system, that will allow you to generate a 32 bit
timer.
The upper 16 bit timer will be clocked by an event coming from the lower
16
bit timer.
IIRC, The hispeed will work in PWM mode only, but you can use the timer as
a
32 bit
Capture timer at 32 MHz.

The Xmega have nice peripherals, is there a AVR32 with the same
peripherals ? (or will the new cortex devices use some of the xmega ideas
?)

The XMEGA does not have the AMBA bus, but Atmel has already
said that the UC3C will use some of the ideas from XMEGA.
The contents of other circuits are yet to be revealed.

I do like the better peripherals in the NXP Cortex releases.

Challenges are always nice!

-jg

--
--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[David Brown]

it has strings, and what else? "with"

"with" is very useful - it can make some kinds of code a lot clearer,
and it is easy for the compiler to optimise it (for example, if you have
a "with" block on a record in an array indexed by a global, the compiler
can easily use a pointer for all the accesses. Without "with", a C
compiler may have to be conservative and re-calculate the pointer).

can it create arrays of a size determined at run-time? (can it?)

Yes, and you can also get the size of arrays passed to functions (arrays
are a different type from pointers).

haw about variadic functions (I don't think it has them)

I don't know - why would you want variadic functions in a strongly typed
and strongly structured language?

Higher level concepts that Pascal has are proper enumerated types,
integer range types (both of which give much better compile-time
checking), and local procedures and functions (which improve modularity
and structure).

Sets are another very useful higher level concept.

Pascal also has proper modules with separate interface and
implementation sections (though not as good as Modula-2, which has them
in separate files). Of course, header files can give a similar effect
in C - *if* they are properly used (too much flexibility is a bad thing
sometimes).

Depending on the version of Pascal (standard, extended standard, or
commonly-used non-standard extensions such as Borland's Pascal or gpc),
you also have features such as overloading, classes, exceptions, etc.,
somewhat similar to C++ (which is also higher level than C).

uudecode is a relatively low-level process,
for every 4 pack the least significant 6 bits of each toegther to make
3 bytes, how would you write that in pascal.

Again, this is as easy as C if you have the very common but non-standard
bitwise operators ("and", "or", and shift operators).

(I can see two ways to do it in C, one of them exposes no arithmetic
but is non-portable but that could probably be solved with a #define
if portability is an issue)


well for the most part that's true, the few things that are more useful
for pascal or more useful for C aren't extremely exciting or a great
hardship if they aren't available.

When I've been working with Delphi for a while, and go back to C
programming, I find I miss the better type support (enumerated types,
subranges, and sets) most.

I've not looked closely at this, but I think for most 8-bit expressions
things can be written to use only 8 bits

You can't - C requires that all arithmetic on 8-bit expressions is
promoted to "int". This includes switches, and even "if (x) ... "
statements. A good 8-bit embedded C compiler will hide most of the
effects and through away the top half of these calculations, but it will
not always be optimal.

 

[CBFalconer]

Same here. I worked on real-time embedded systems in Pascal
(including an RTOS kernel). With a few minimal extensions
Pascal was a great language in which to do low-level embedded
systems. Unfortunately, Pascal died off, and now I use C
_with_a_few_minimal_extensions_ for such applications.


It seemed to me that the Modula family of languages would be
even better for embedded work, but they never became popular.

Take a look at Ada. Since it is now a member of the gcc family, it
is available wherever gcc has been ported. It also has a proper
standard, and is a descendent of Pascal and Modula.

Please don't remove attribution lines for any material you quote.
I have restored them above, hopefully correctly.

 

[CBFalconer]

it has strings, and what else? "with"

can it create arrays of a size determined at run-time? (can
it?). haw about variadic functions (I don't think it has them)

Yes, for level 1. Variadic functions are not necessary, and in
fact are major error sources in C. Pascal supplies them for read
and write operations in a form that avoids the error problems. C
doesn't provide the look-ahead file buffer (via f^) and put or get
functions. However Ada provides the abilities, and is a modern
language, and is also widely available. Ada also provides
designed-in access to object code written in other languages.

 

[CBFalconer]

It did. TurboPascal was a huge success. Back in the CP/M days
(DOS was a copy of CP/M), Pascal was pretty much _the_
programming language (besides assembly) for micro-computers.

When I was in school in the early 80's and it came time to do
high-level programming on a micro-processor, we used Pascal and
HP in-circuit emulators. At my first job in 1983, I wrote
cellular telephone firmware in Pascal.

At my second job I wrote firmware in C and data-analysis
programs in Pascal.

At my third job, it was just C.

Pascal did "take off" -- then it landed.

Unfortunately Borland did not meet the simple requirements of the
Pascal standard, which they could have easily done when they
brought out TP4 (about 1988). IMO this is heavily tied to the
death of Pascal.

I fixed the attributions again.

 

[CBFalconer]

What string support does Pascal have? Lack of a string type
is a major deficiency (of the original standard Pascal).

You don't have to stick to ISO7185. Try ISO 10206 Extended Pascal.

 

[Frank Buss]

C doesn't provide the look-ahead file buffer (via f^) and put or get
functions.

At least there is ungetc in C. But I don't think this is very important,
because you can build your own functions for simulating it, if you really
need it. But if you use e.g. flex and yacc for parsing, this is all handled
for you by the parser generator anyway.

 

[[email protected]]

It sounds like you haven't ever actually used Pascal, but rather some
kind of non-standard extended Pascal. In you're going to claim that
Pascal is useful for low-level programming, please explain how to
efficiently perform common low-level tasks, such as to set bit 5 of a
16-bit integer (assuming that bit 0 is the LSB), or to compute the
logical AND of two 16-bit integers.

I use "or" and "and" just like everyone else.

If you think standard Pascal has features to do that, perhaps you
can point us to the relevant section numbers of the ISO standard.

Excuse me, what century is this? I find it hard to believe people are
still using the ISO straw man to knock Pascal. Who actually uses ISO
standard Pascal for embedded systems?

You don't like Pascal, we get that.

 

[Paul Keinanen]

it has strings, and what else? "with"

What string support does Pascal have? Lack of a string type
is a major deficiency (of the original standard Pascal).[/QUOTE]

Does C have any real character string support ?

The only "string support" C has is putting an extra null after the
last quote character in the source code. The rest of the string
operations are handled by (standardized) library calls.

Apart from the terminating null in constant strings, even FORTRAN IV
would have a string support similar to C, but IMHO even Fortran77 has
a better character string support than C on the language level.

While I like null terminated strings when programming in an assembly
language, does it really belong to a high level language ?

Paul