Microchip ICD4 ?

Yes and exception handling, they're self contained cold bootable binaries. Flash them to the targets and the LED will blink.

Definitely not.

A Forth Blinky is too big to include in a "smallest size binary contest" as the Forth core is also required. Otherwise a Forth Blinky is the easiest to make.

Yes, I'm evaluating "Mecrisp-Across" at the moment. The binary runs on MSP430 targets, but "Mecrisp-Across" is written in Forth and runs on Mecrisp-Stellaris, hosted on ARM, be it a RaspberryPI, STM32, TI Tiva Connected Launchpad or about 5 other manufacturers ARM products.

He has, but because Matthias is a *very* fond of MSP430 Assembly and always wanted to make a super optimised tethered Forth compiler, MSP430 was a logical choice. I wouldn't hold my breath waiting for a ARM version.

He has made Mecrisp-Stellaris for CortexM, it's cold bootable turnkey capable and only 19K with the latest RA version and Vocabulary hooks. I feel it's very capable, and the price is right.

STM32F CortexM variants with 64K Flash are dirt cheap and what I use. I paid $0.56 USD ea for STM32F051 in 32 pin QFN with 64K flash from Avenet a couple of years ago.

On the other hand MSP430 are very expensive in comparison to STM32F, so I think Mecrisp-Across Forth hosted on ARM and generating binaries for MSP430 chips is a great idea.

Mecrisp-Across Forth, apart from generating MSP430 binaries, also allows target I/O control via JTAG, which is pretty cool.

Mecrisp-Across, is still very Alpha, but can download it here

formatting link
experimental.tar.gz

Cheers, Terry

--
Mecrisp-Stellaris Unofficial User Doc: http://128.199.141.78/index.html
Reply to
Terry Porter
Loading thread data ...

Why not ? I've written in assembler since mid 70's. Guess that makes me a Dinosaur :(

--
This email has been checked for viruses by Avast antivirus software. 
https://www.avast.com/antivirus
Reply to
TTman

My mileage has never varied, assembly always beats a compiled language Blinky in code size in my experience.

No, because while -Os does make the binary smaller, it optomizes away the blinking, a common hardware issue.

--
Mecrisp-Stellaris Unofficial User Doc: http://128.199.141.78/index.html
Reply to
Terry Porter

Then it is not a fair comparison. A C compiler won't have any way to pare down the startup code to eliminate a bunch of initialization that won't be needed. I guess that goes along with the example being rather "trivial".

Sorry, that is not the case. A Forth compiler can compile a stand alone executable just like any other compiler.

"But"??? Why "but"?

Yes, that's what I said. I asked him and he said it would be a while before he considers it. I assume some if not much of the optimization would be different for the two CPUs, so a lot of work for an ARM version.

I know, I've used it... on a Stellaris in fact.

Oh yeah, I know you. You are the guy with the web site that only uses the IP address. I'm not good with names when I can't connect faces to them. I was talking to you about adding documentation to your site for the MSP430 Mecrisp.

I don't follow the reasoning. An MSP430 with 128kB of Flash and 16kB of RAM is only $2.30. I think that is affordable for a development system.

I don't have one of the host boards, so I'm going to wait until I have a need. Thanks for the link.

--

Rick C
Reply to
rickman

I think writing *any* code since the 70's makes you a dinosaur. ;)

--

Rick C
Reply to
rickman

to:

If it does, it's because you wrote a very bad C code.

Bye Jack

Reply to
jack4747

That sums it up. You write code to do something, the compiler makes it do something else, but it's somehow your fault. Not the compiler writer's, no siree bob.

Like = and == in C. Get those wrong and it's your fault, no blame at all attached to the donkeys who designed it for unreliability.

I like assembler. What you see is what you get, and there's no-one to blame but yourself. Use a compiler, and there's a black box designed by somebody else in the way. Yes, I know you have to for many/most things.

What I don't like about assembler is the pointless limitations on positioning and labels.

Cheers

--
Clive
Reply to
Clive Arthur

Quite right ! I started with the Intel 8047/8 and swiftly moved to the

87 series with on board Eprom. I designed/built a rally navigation time/distance meter with it.....and laterly Laser Tag using 89C51ED2s
Reply to
TTman

volatile usually fixes such loop invariant optimisation problems. (but not always if your code looks too much like a benchmark!)

The alternative is := and = in Pascal and Modula 2. Then people grumble about all the extra typing so you can't win.

Assembler doesn't scale well to large projects. We learnt that very early on when autocode was developed as a stepping stone to compilers.

--
Regards, 
Martin Brown
Reply to
Martin Brown

C++1x is a generic term for C++11 onwards (C++14, the up-coming C++17, and the future C++20). C++ had a significant change with the 2011 standard, including "auto" type deduction, compile-time code evaluation, lambdas, strongly typed enums, multithreading, etc.

Used well, this can let you get more code safety and code efficiency than was possible before (with C++03, or C). I don't know that it will give you a lot more code efficiency, but I can imagine it helping somewhat.

I like to be a little careful about claims of greater efficiency than assembly - after all, it is trivial to see that anything a compiler can generate could also be written directly in assembly. I prefer to say that compilers can, in most circumstances, generate more efficient code than assembly programmers when the code is to be maintainable, flexible, understandable, somewhat portable (say, amongst different ARM chips or different x86 chips - devices that share the same basic assembly, to make the comparison fair), and developed in a sensible amount of time.

As a simple example, lets consider a scaling routine:

static const int divFactor = 2815; static const int multFactor = 31214;

int scale(int x) { return (x * multFactor) / divFactor; }

How should that be implemented on an ARM?

The obvious assembly for a Cortex-M4 would be:

scale: movw r3, #31214 muls r0, r3, r0 movw r3, #2815 sdiv r0, r0, r3 bx lr

But is that the fastest method? No, division is a slow instruction. A faster M4 version would be:

scale: movw r3, #31214 ldr r2, .L2 mul r0, r3, r0 smull r3, r2, r2, r0 add r2, r2, r0 asrs r0, r0, #31 rsb r0, r0, r2, asr #11 bx lr .L2: .word -1170245085

The division has been turned into a collection of adds and shifts.

If you vary the constants even just a little, the assembly code here can vary significantly. Sometimes common factors can simplify the code. The numbers, types and orders of the adds and shifts will vary. Sometimes they are best replaced by another multiplication. Sometimes the original multiplication is best replaced by shifts and adds. On different ARM devices, details of the timings and the instructions supported can mean that different choices are optimal.

And when this function is actually used in code, inlining, constant propagation and other optimisations can mean that the ideal code could be completely different - including being calculated at compile time.

So yes, an assembly programmer could write code for this function, using either of these formulations. But he/she has a choice between writing a clear, flexible and maintainable version - or a faster version. Only a compiler can give you both.

(I cannot tell you if a Forth compiler can generate object code like this - I know they can do /some/ optimisations, but I have no idea of the details.)

Reply to
David Brown

critto:

the

the compiler follows rules. If you don't follow them when writing code, you can't blame the compiler if it does things that you don't want.

at

that's more or less the same as using a arithmetic shift instead of a logic al in assembler, of course it's not your fault, it's the donkeys who wrote the instruction set: the CPU should have a crystal ball and understand what you want even if you write it incorrectly.

Bye Jack

Reply to
jack4747

The Commodore 64 used a 6510 processor, not the original 6502. It has a built in port that interfaced the cassette port, and a few other non standard functions.

--
Never piss off an Engineer! 

They don't get mad. 
 Click to see the full signature
Reply to
Michael A. Terrell

In our VFX Forth compiler, there's only one algorithm that's not in the compiler literature. Code generation is all about a myriad of details. Where gcc (in particular) wins is in the huge amount of time and money spent on the ARM and x86 versions (in particular). There are algorithms for languages with static call trees, e.g. C, that do not apply for languages with dynamic call trees, e.g. Forth.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

No. A logical shift and an arithmetic shift do different things and have different names, whereas = has been used for ever (donkeys' years!) to mean 'equals', or 'is equal to'. To then specify that symbol to mean 'is replaced by', and to invent the new symbol == to mean what

*everybody* was taught that = means, is wanton stupidity.

I wasn't brought up with C in college, so I am allowed such blasphemy.

Cheers

--
Clive
Reply to
Clive Arthur

Well, go ahead, and try the challenge I have stated for nasal demon worshippers*:

Write a proof-of-concept Forth interpreter in the language you advocate that runs at least one of bubble-sort, matrix-mult or sieve from bench/forth in

  • I don't know if you are of that religion, but belief in compiler supremacy often goes with nasal demon worship; if you don't know "nasal demon", you probably don't worship them.

Followups set to comp.lang.forth

- 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 
 Click to see the full signature
Reply to
Anton Ertl

Programmers who think that are likely to produce code that's not just a little slower, but much slower. That's because they have no idea what compilers can do and what they cannot do.

As an example, I know of a microprocessor simulator that was written in C++, and it was, in a sense, well-written C++, using lots of abstractions. The resulting simulator worked, at 300 simulated cycles per (wall-clock) second. That was much too slow to be useful, so they threw it away, wrote a simulator designed for efficiency (that ignored all the great software engineering features in C++), and the result simulated at 3M simulated cycles per second, which was good enough.

Compilers may put in crazy contorted optimizations, but that does not mean that the resulting code is fast. For any sizable program, there are so many stumbling blocks to optimization, that a compiler working on some high-level code is unlikely to get as good a result as a programmer expressing the code more directly. Plus, compiler supremacists are unlikely to be aware of these stumbling blocks, but even for someone like me, who is aware of them, trying to work around them is more effort than writing the code more directly to begin with.

As an example of the inability of compilers to make source-level optimization by programmers unnecessary, take a look at Section 4.2 of . The source-level optimizations are from a book that was 33 years old at the time, and yet the optimizing compilers performed only one of these optimizations (inlining). Apart from that, the compiler optimizations seem to be orthogonal to the source-level optimizations. In later work, I and others could achieve another factor of 2.5 using assembly language, but you may consider that as an example of a small, tight loop.

- 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 
 Click to see the full signature
Reply to
Anton Ertl

With profile directed compiler optimisation on deep pipelined CPUs with speculative execution it is getting increasingly more difficult for the human assembler writer to keep up with the best optimising compilers.

It isn't usually worth the effort any more.

--
Regards, 
Martin Brown
Reply to
Martin Brown

...

2815 constant divfactor 31214 constant mulfactor : scale mulfactor divfactor */ ; : scale1 mulfactor * divfactor / ;

VFX and SwiftForth (for IA-32) use IDIV in both variants, for iForth I don't know how to see the generated code (SEE produces something resembling the source code).

However, the Forth way is to let the compiler and the programmer work hand-in-hand, and for this particular case, the solution already exists (as long as x is not negative):

formatting link

include compat/stagediv.fs

2815 constant divfactor 31214 constant mulfactor : scale mulfactor * [ divfactor ]u/ ;

VFX: SCALE ( 080C0D50 69DBEE790000 ) IMUL EBX, EBX, # 000079EE ( 080C0D56 68EF471700 ) PUSH 001747EF ( 080C0D5B B8EA064C44 ) MOV EAX, 444C06EA ( 080C0D60 F7E3 ) MUL EBX ( 080C0D62 59 ) POP ECX ( 080C0D63 8D6DF4 ) LEA EBP, [EBP+-0C] ( 080C0D66 895D00 ) MOV [EBP], EBX ( 080C0D69 C7450400000000 ) MOV DWord Ptr [EBP+04], 00000000 ( 080C0D70 895508 ) MOV [EBP+08], EDX ( 080C0D73 8BD9 ) MOV EBX, ECX ( 080C0D75 8BC3 ) MOV EAX, EBX ( 080C0D77 F76500 ) MUL [EBP] ( 080C0D7A 034508 ) ADD EAX, [EBP+08] ( 080C0D7D 135504 ) ADC EDX, [EBP+04] ( 080C0D80 8BDA ) MOV EBX, EDX ( 080C0D82 8D6D0C ) LEA EBP, [EBP+0C] ( 080C0D85 C3 ) NEXT, ( 54 bytes, 17 instructions )

No DIVs, although quite a lot of MOVs. The SwiftForth variant executes more code. iForth disassembles this time around:

$10226440 : scale 488BC04883ED088F4500 snipped-for-privacy@H.m..E. $1022644A pop rbx 5B [ $1022644B imul rbx, rbx, $000079EE d# 4869DBEE790000 Hi[ny.. $10226452 mov rax, $5B084692:0D470675 q# 48B87506470D9246085B H8u.G..F.[ $1022645C mov rdi, rbx 488BFB H.{ $1022645F xchg rdx, rdi 4887FA H.z $10226462 mul rdx 48F7E2 Hwb $10226465 xchg rdx, rdi 4887FA H.z $10226468 mov rax, $001747EF:444C06E9 q# 48B8E9064C44EF471700 H8i.LDoG.. $10226472 xchg rdx, rbx 4887DA H.Z $10226475 mul rdx 48F7E2 Hwb $10226478 xchg rdx, rbx 4887DA H.Z $1022647B add rdi, rax 4803F8 H.x $1022647E adc rbx, 0 b# 4883D300 H.S. $10226482 push rbx 53 S $10226483 ;

Also no DIV.

- 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 
 Click to see the full signature
Reply to
Anton Ertl

This is, of course, a completely pointless "contest". It is like trying to compare two athletes in a 2 metre sprint.

But just for a laugh, I tried to get a minimum msp430 blinky program. I picked an msp430f2619 device, because I have one, and port 2 pin 0 for the LED (driving 0 to turn the LED on). I have not tested the code at all.

I got 22 bytes with C code:

#include #include #include

uint8_t resetCounter;

void __attribute__((naked)) xreset(void) { resetCounter++; if (resetCounter & 0x20) { P2DIR = 0x01; } while (true) { // Wait for reset } }

00002100 : 2100: 5f 42 00 11 mov.b &0x1100,r15 2104: 5f 53 inc.b r15 2106: c2 4f 00 11 mov.b r15, &0x1100 210a: 3f f0 20 00 and #32, r15 ;#0x0020 210e: 02 24 jz $+6 ;abs 0x2114 2110: d2 43 2a 00 mov.b #1, &0x002a ;r3 As==01 2114: ff 3f jmp $+0 ;abs 0x2114

Compiled with:

msp430-gcc blink.c -mmcu=msp430f2619 -nostartfiles -nodefaultlibs

-nostdlib -Os

The program relies on the watchdog to reset the chip after approximately

30 milliseconds, and has the LED on for 32 rounds, then off for 32 rounds, for around 1 second blink.

I am curious about assembly code that will beat that.

Reply to
David Brown

The other direction would be more interesting for the question he asked.

The call trees of C look every bit as dynamic or static as those of Forth. The major differences are that you may have to compile a part of the code before seeing all of it, and that you cannot spend much time on compilation (because it's part of the run-time).

- 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 
 Click to see the full signature
Reply to
Anton Ertl

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.