A chip too far? Where is your solution Mr Larkin?

The DOS version of PowerBasic is essentially the old Turbo Basic, coded in assembly. The PBCC (32-bit) version compiler and IDE are programmed in PowerBasic! It's a really good compiler and a very nice language. One of the best things about a modern basic is the PRINT USING (or USING$) capability, where you can format a line of mixed variables exactly the way it will display. And the inherent string variables and functions are great.

TCP/IP is absurdly simple. It's even easy to send and receive emails from inside a program.

If only Windows would let me get at the good stuff...io ports, memory mapped i/o, pci config space.

John

Hopefully you would agree that you need to propose a security model as well, then. It's reasonable to want a machine with an "engineering" mode where any program can do whatever it wants, but you definitely don't want the average user to be running their desktop PC in a mode such that the first BASIC program they download can directly access the hardware and begin formatting their hard drive in well under a millisecond.

For your needs, there are various software packages that let regular user mode programs access hardware directly (essentially they're a "generic" device driver...) -- Jungo is popular, for instance, although it might need something like a COM wrapper so that you can use it from PowerBasic?

---Joel

Take a look at the "Programming Tools for Port I/O and Interrupts" section at [

I am pretty sure that the PBCC compiler is written in assembly laguage.

On Tue, 19 Aug 2008 15:57:50 GMT, in sci.electronics.design, Jan Panteltje bloviated:

core,

RPU - Reconfigurable Processor Unit

Dynamic configuration of FPGA on an application basis.

Some Windows utilities, like TOTALIO, will booger the x86 permissions map to allow port i/o from user level. I just wish I could map any physical memory into an addressable array, specifically hunks of the PCI bus. I could do that under DOS.

It was originally, but I read somewhere that the latest version was coded in PBCC.

John

Fascinating! That would imply that the compiler produces output that Bob Zale considers to be good enough to replace his hand-coded assembly.

Then again, maybe he did what I do; write in a HLL, profile to see what part is taking 90%+ of the time, and writing only that portion in assembly language. PBCC does have nice inline assembly language support.

The problem is that, fundamentally, it's the only one.

Do note that DES was designed to be done in hardware. In fact, if it's not implemented in hardware it's not DES.

However, the world seldom has only one problem to work on at a time.

What? And have them bury it along side the 100MPG carburetor? ;-)

What is "it"?

core,

If it's that important, put it in custom logic. FPGAs can't compete here either. It's all a trade-off (it's called "engineering" ;).

D'OH! (hangs head in shame)

Note to self: [1] Prufreed before posting. [2] Smoke crack *after* posting.

Eh, ASM FP is easy. Like, a whole lot easier than most fixed point code (especially extended precision operations).

-=-=-=-

; ; Travel contains factors of xSlope * ySlope. Divide them out, ; and multiply in some other factors. ;

finit ; initialize FPU fild Raysm.Travel fmul FP fidiv Raysm.xTravel fmul FP fidiv Raysm.yTravel fistp Trav ; Trav = (((Travel * FP) / xTravel) * FP) / yTravel

-=-=-=-

In comparison, I also have this procedure:

-=-=-=-

; ; Multiplies a fixed-point DWORD (16.16 format) by a fraction (0.16). ; Input: on stack (DWORD, WORD) ; Output: DX:AX = DWORD product. ; fixedByFrac PROC near USES bx cx si di fixed:dword, frac:word mov di,wpr fixed+2 mov ax,wpr fixed mov bx,frac xor si,si test bx,bx ; get fraction sign jns @F not si neg bx @@: test di,di ; and fixed's sign jns @F not si neg di neg ax sbb di,0 ; and flip fixed's sign @@: mul bx mov cx,dx ; frac * frac, save high word mov ax,di mul bx ; num * frac add ax,cx ; add fractional adc dx,0 test si,si jz @F neg dx neg ax sbb dx,0 @@: ret fixedByFrac ENDP

-=-=-=-

As you can see, multiplying signed integer arguments is a bit of a pain when you don't have the bit width to do it in one operation (and the 386 does that multiplication in like 30 cycles, vs. 120ish for the 8086 on one 16x16 product).

Tim

MASM has those:

jnz @F ; forward ... @@: ... loop @B ; back

I'd say the most obvious local label is one that is explicitly local. Get a "better" assembler ;-)

Tim

Oh, call it a typo on that level. I use QuickBasic 4.5, which is pretty close to 4.0. I doubt the calls are any different in QBasic 1.x.

Tim

Some assemblers do local labels in various ways. MACRO-11 used labels like 1$ 2$ whatever, whose scope was limited to between two real labels.

But MERLIN is just as good as 14$ or @@, and easier to pronounce.

You can pick a theme for throwaway labels; animals, current events, brands of motorcycles, former girlfriends, current girlfriends.

John

NOT writing the compiler in PowerBasic would be an admission of sorts.

Burroughs used to program all their machines in Algol, including the Algol compiler. They wrote the first compiler in Algol, and two guys, reading the compiler source, hand-compiled the first edition directly into machine code. After that, they could pass it through itself.

The IDE is 630Kbytes. The compiler is 317K. The utilities that I write tend to run in the 30-70K compiled sort of range, not that it really matters any more. The graphics aren't bad either.

John

In which case I would argue that on cohesion and coherence grounds the FLAGS and RED variable should be maintained and updated there.

MERLIN is guaranteed to always get executed, but if commands hit the unit thick and fast the PSU will never get checked by PUPPY. It has to make 32768 loops before that happens.

That you do not follow good housekeeping and note when routines trash the status register does not surprise me. You are every bit as guilty of bad programming style as the software engineers you so denegrate.

The routine could be tidied up with advantage for future maintainence. One day someone with a dislike of rats nest goto code will make the change I have suggested or a similar one and break your code.

If you really are concerned about absolute minimal latency then you could test for command available at the start of the loop. But you no longer get any flags updated at all if that condition is satisfied.

Incidentally you could remove the CLEAR SLOPPY.W completely and then you would be guaranteed eventually to execute all paths no matter how fast commands were receieved. You are after all depending on the register overflowing for correct behaviour of this code.

Why not use a local label designator then. Or does your assembler not support them? MERLIN looks like he should be called CALIBTEST. (let me guess - your assmebler doesn't support labels longer than 6 chars)

Modern emulators will count the cycles for you. There are some cute tricks possible with them.

Regards, Martin Brown

On a sunny day (Thu, 21 Aug 2008 18:08:09 -0500) it happened krw wrote in :

Nope, as I stated, _if_ you want more speed, look where the program spends its time. Then optimise that part, use hardware. These guys got it:

It is not just DES, sure DES designed so it could be easily done in hardware. Nearly any thing that uses DSPs to speed up signal processing can now be done (and perhaps faster) in FPGA.

The issue is, what part of the software can be allocated to FPGA as resource.

You must be aware, that most programs with multiple threads have very different load factors for the threads, some threads may just wake up occasionally, while others do the heavy work (eat CPU cycles). So adding cores for each thread makes no sense, as those cores would do next to nothing, adding one core to do all the low intensity threads even makes no sense, as such a low intensity thing can then just as well occasionally run on the main CPU. Mr Larking has some idea it would be safer to spread threads over all cores, but there is no proof of that. Safer then 100% reliable is not possible anyways (Like a good Linux system :-) ).

I think the universities, big companies like Intel, IBM, Altera, Xilinx, and the above mentioned companies that already have solutions, should get together to make some open compiler / specification so it can be done automatically. You see that a 100x speedup for a big database using one FPGA based module in a spare CPU slot is a lot, it would take 100 cores extra to do that, if cores added linear to speed. So, throwing more cores at the problem is the wrong method, may seem easy if you are used to use cores for everything, but they have to let go of that idea.

time.

makes no sense,

main CPU.

).

the above mentioned

compiler / specification

spare

linear to speed.

you are used

So write a letter to Intel and tell them that they're all wrong.

John

Well, I suppose that makes you a programmer. I'm an engineer, so the "grounds" I use is whatever works best.

The red led blinks if something's broken, and doesn't blink if it's not. A millisecond early or late on a blink isn't a problem worth fixing... I have other concerns.

I don't see that. SLOPPY is never cleared, so eventually it rolls and the +12 supply gets checked. The loop runs about 40,000 times per second, and the baud rate is 38K, and I don't care too much is the power supply is checked every second or every 5 seconds.

But it works, it's bug-free, and it makes money. You would prefer more conventional programming, bloat and bugs?

I suspect you would break my code. You probably break your own code.

Remove what?

It does. I don't.

Damn but you are prissy. All I do is write code that works.

John

On a sunny day (Fri, 22 Aug 2008 07:24:18 -0700) it happened John Larkin wrote in :

time.

makes no sense,

main CPU.

but

).

the above mentioned

compiler / specification

a spare

linear to speed.

you are used

Why, because they sue websites with the word 'inside' in it? Why in the world would I help Intel? Anyways they KNOW:

It is easy to say: 'Everybody makes crap, our products are perfect.' That is sales talk (and bad at that, as it upsets every other company). But one of these days complexity is needed, speed, at least for some segments of that market, and if you want to compete you better have the real stuff. Computing has moved a a lot since TI45 calculators and pencil drawn diagrams, and electric pencil sharpers, 68000 CPU, remember Motorola Maxboard?

its time.

different

makes no sense,

main CPU.

but

:-) ).

the above mentioned

compiler / specification

a spare

linear to speed.

you are used

Do I have to give all the money back?

One of the reasons we don't need massive computing power in our embedded products is that stuff is progressively moving into FPGAs, with the uP doing relatively slow setup, housekeeping, and user interface, as the FPGA does ever-more complex stuff at increasing speeds, all in parallel at hundreds of MHz.

In one recent case, we moved a calibration routine, a multiply, a couple of saturating adds, and a long signed divide, multiple ranges times 16 channels, from uP code into FPGA hardware. That radically simplified my code... I only load the cal coefficients from eeprom into the fpga at startup time, and then just poke the normalized data as I get it.

Another small example of parallel hardware and zillions of transistors simplifying what would have been a complex procedural software approach. Get used to it.

We'll move onto one of the Coldfire chips some day, when we come across a problem that needs more horsepower, but doesn't justify just dropping a mini-ITX motherboard into the box. For $300 or so, with all those goodies like gigabit ethernet and flash and ports and Linux and stuff, it's hard to beat an x86 board for box-level products.

John