ARM Port of FreeBASIC

[wolfman775]

Is it possible to get arm7/9 asm from the freeBASIC compiler, and if not is there a way to convert x86 to arm7/9 without learning it, because I would love to use freeBASIC to program homebrew for the DS.

If anyone can think of a way of making a homebrew DS app using freeBASIC please notify me.

[angros47]

Is it possible to get arm7/9 asm from the freeBASIC compiler

Yes it is, but it would require an emitter specifically built for ARM (to write it you'd have to know very well ASM assembly and FB structure), or a C emitter (currently being worked on) that produces C code that can be compiled with GCC for ARM.

and if not is there a way to convert x86 to arm7/9 without learning it

No, because there's not only the ASM code, there's also the interrupts, the memory map etc... so you'll have to emulate the entire x86 architecture to do that (with a big waste of memory and speed).

because I would love to use freeBASIC to program homebrew for the DS.

You'll have to wait, because even with C emitter (it's not complete, but it already works) and a GCC compiler for DS (like the one used to build DSLinux), you'll still need a port of the runtime library and of the graphic library.

[wolfman775]

Another idea I had would be to make a DS port of DOS, because then you could use the C emitter and compile a DOS program for the ARM arcitecture and then run that like a normal DOS program, but no-one would make a DOS port to the DS because it would be almost useless because everything for it would have to be re-compiled but I would love a port of DOS to the DS.

[angros47]

There already is a port of linux for DS, called DSLinux (very original ;-)
So you can use FB for linux with C emitter, then compile with GCC for DSLinuc .... in theory.

[wolfman775]

Genious! I never thought of that, because I never use linux I was only thinking about the windows version, BUT How do I cross compile from windows to linux?

[angros47]

The same source code can be compiled with the linux version of FB.
Since the C code is still not perfect, you may also try compiling to C with windows, then compiling the C code on DSLinux (you will, anyway, have to adjust the resulting code: DSLinux is not a complete linux, so it may lack some features)

[roook_ph]

Sounds too good to be true . Linux on non x86 machines is too cumbersome. there is a lot of emulating involve.I tried it before with linux on my old gamecube.And Ive had enough of downloading and booting and the machine got ruined before I can even boot one linux log.

[TodWulff]

FWIW, there is a good BASIC Compiler for ARMs from Coridium Corp. (www.coridiumcorp.com). It is called ARMbasic.

It is not freeware, however, so it doesn't conform to the OSS philosophy.

However, I am a customer of theirs, and I would certainly endorse it.

YMMV...

-t

[adx]

Dredging this up because I have been interested in a similar thing since FB first came out - using it to compile for embedded microcontroller targets, either directly (I got a fair way through the source before I decided it was too much), or via C which is what most micros are programmed in these days and the obvious way to go.

Specifically ARM. The Coridium product looks good, but has to be licensed per item so is rather useless unless already buying their hardware. I would like to be able to use BASIC on the Cortex M0 for example. No OS, just straight on the hardware.

Another example is Atmel AVR, via WinAVR (GCC toolchain), but these are things with only a few bytes of RAM to play with - some don't even have RAM, just a regiser set (32 bytes). Still, there are C compilers. This would compete with things like MCS Electronics BASCOM, which I use, a great example of "how to do it", but is (a) almost completely not optimised and (b) not portable to other processors I'd like to use eg PIC, PIC24, MSP.

BASCOM (the 8051 version at least) does win on having no "runtime library" as a kind of inherent optimisation, for example
PRINT chr$(34)
compiles directly to something like
mov Txbuf, #34
(where Txbuf is the HW register for the UART transmitter so this is literally one instruction, maybe it waits for the "empty" flag first which is only one more - I forget 8051 assembly)

Maybe that sort of thing is beyond a modern compiler, or maybe optimisers are that good these days? The closest I've seen is HiTech's "omniscient" compiler for PIC18 which compiles the entire source incl libs with aggressive optimisation on each build rather than going to all the effort then just linking precompiled libs (an obvious thing I would have thought).

What really is handy in these "micro BASICs" is support for hardware bit manipulation (that looks rather like VB), in fact from an earlier post somewhere...

C bit operators are horrible. they just are.
In BASIC:
PORTB.3 = 1 'set bit
PORTB.3 = 0 'clear bit
x = PORTB.3 'read bit

these are illegal in C
you have to resort to macros, functions or some other arcane syntax
the C-heads will want to shoot me down in flames, saying something like

"
Exactly what is so complicated about:

PORTB |= _BV(PB3); // set bit 3
PORTB &= ~_BV(PB3); // clear bit 3
x = ((PORTB & _BV(PB3) == _BV(PB3)); //x gets state of bit 3

It's hardly the most complicated C ever is it?!?
"
(a real example from a post at
http://www.avrfreaks.net/index.php?name ... ic&t=31109))

Once you're used to C it is fairly easy to read through the fluff and unnecessary function calls, but if you're not a full time SW engineer (many embeded programmers aren't because they deal with hardware) then it can get too much, to the point where assembly is really a lot easier.

Hence my interest in using something "nice" like FB as a universal front end for low-end and mid-end devices.

[adx]

Just found another post on this subject by searching for "winavr". Winavr is a good place to start because the project is mature and seems to have inspired other manufacturers to jump onto the GCC bandwagon.

[fsw]

FYI:
Did you look at GreatCowBasic ?

AFAIK they used FreeBasic as a base and target microcontrollers.

BTW:
If you want to use WinAVR don't use any 2008 or 2009 editions as they contain bugs in respect of interrupts (run into these while using interrupts myself...).

Use the WinAVR December 2007 release instead - it's more reliable.

[adx]

Thanks for the tip about WinAVR. I usually avoid C but I'm going to have to use it some time.

I did check out GreatCowBasic a bit over a year ago, but then it only supported 8 bit PIC and looked rather unfinished. Also I remember seeing all the #defines and thought it was a C-based dialect (rather than using CONST etc). My mistake.

I had no idea it was based on FB! Many years ago when I had a go at this idea myself (for ARM) I made the decision to stop and wait for the GCC generator, a wise decision after looking at the GCB compiler source because it's just as much work as I expected. I'll certainly have a better look at GCB now though, especially as it has library support for PIC and AVR. BASCOM-AVR is still a lot more polished (even if it based around what can only be called an "un-optimising" compiler).

But all that highlights how important the C route is now though, even though I never really liked the idea. If I want to target an ARM, and with Cortex M0 around who wouldn't, then who comes up with that BASIC? Because it's so much work, it's some random crowd who add yet another tool and subtly different dialect to the mix. The C guys don't have to worry about this, apart from platform specific functions which are usually fairly well standardised from a particular vendor (eg IAR).

Speaking of different dialects, I wrote a very basic "BASIC assembler" for PIC many years ago (in QB), which just converts BASIC syntax to assembler and provides some wrappers to simplify flow control. I still use it if I need to do any small PIC assembler jobs, and give it to the client so they can continue to use the preprocessor if they want. Stuff like this...

Code: Select all

	 ADLOOP
	  w = i				;generate LUT address,
	  ifbs i, 7			;and if necessary
	  comf i, W			;'mirror' it,
	  call LUT			;look up filter coefficient

	  ifbs mod_in_PORT, mod_in	; if comparator output low
	  goto NO_COUNT			;
	   ad_inL = ad_inL + w		;mult+accum coefficient with input

etc

[marcov]

"ARM" is a large concept. There are many variants (EABI/OABI/VFP/THUMB1/2)

Anyway, if tested is needed, I've a couple of WinCE PDAs and a Sheevaplug to test.

[adx]

For ARM, theres also...

The ARM® Cortex™ Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer for the Cortex-M processor series. The CMSIS enables consistent and simple software interfaces to the processor for interface peripherals, real-time operating systems, and middleware,...

Which could be a fly in the ointment for those wishing to come up with some new or "BASIC style" ways of accessing peripherals. But it also should lead the way when it comes to targeting FB's GCC to these micros, or at least keep it compatible with the C guys. As long as it doesn't get in the way of BASIC's simple syntax (per my example a few posts above) or impact code size/efficiency too much (less of a worry on ARM compared to an AVR with 32 bytewide registers and zero RAM).

I'm guessing supporting the many types of ARM cores out there will be vastly eased by going through GCC. BTW I had a look at FB's GCC output lastnight and it looks "messy" but up to the task already.

[John Spikowski]

FWIW

The University of Toronto is using ScriptBasic to control all their environmental systems (HVAV, Biosphere, ...) for the campus and has ported ScriptBasic to a dedicated controller. It might be something worth looking into.

http://www.allbasic.info/forum/index.php?topic=484.0