Programming in Basic on Bare Metal Tutorial 1

[mahjongg]

@bobc
Why do you think there is only one way to go from complex-concrete to simple-abstract?
I do know how to program in C, I did it professionally a long time ago, using K&R's book as not many other books were available at that time.
But you might not be aware on how much abstraction a macro assembler can introduce to "assembler programming", given the right macro's you can program with it with "high level constructs". The problem with a compiler is that you never know exactly what code it produces, with a high level macro assembler you do know, and what is more you can tweak it endlessly to make it do exactly what you want, as efficiently as possible.
I think macro assembler never got the chance to prove what they could do, as they were overshadowed first by interpreters, and later by compilers, only very few languages use a different paradigma, one of them is Forth, which may not be for everybody, but does show what is possible without using a compiler or interpreter.

[pygmy_giant]

At the end of the day there is no one 'best' way to program. You can argue the merits of your case and possibly be technically correct, but that misses the whole point of what computers are and what computers are for. Computers are a tool and the best way to use them for problem solving is the way that the the human being doing the problem solving feels most comfortable using them.

Whats best for bobc may not be best for pygmy_giant and whats best for pygmy_giant may not be best for DexOs and whats bes for DexOs may not be best for ...

Jimi Hendrix restrung his guitar and played it upside down and arguably acheived reasonable results, although not be to eveyone's liking. Jeff Healy the blind guitarist plays with the guitare laid flat on his lap. The guitar manufacturers did not design those gutars to be played that way and a lot of guitar teachers would discourage kids from learning that way - but who cares - its what the player feels most comfortable doing. The instrument after all is just a tool for expression - its the result that count.

I get anxious when people get all 'my ways better than yours' about programming - its an art.

[tufty]

Thanks everyone for your support and those that do not like the idea thats fine too.
But remember i am not destroying anything, just giving people a new option.

Quite right.

But you might not be aware on how much abstraction a macro assembler can introduce to "assembler programming", given the right macro's you can program with it with "high level constructs".

To a certain extent this is true, but there are severe limitations as to what an assembler can do in terms of high level constructs. A language solely constructed using a macro assembler will be, at best, massively inefficient. You'll get beaten by naively written C every time. Probably even by BASIC.

The problem with a compiler is that you never know exactly what code it produces, with a high level macro assembler you do know, and what is more you can tweak it endlessly to make it do exactly what you want, as efficiently as possible.

Actually, given enough investigation, you can tell exactly what code a compiler will produce. It is, after all, a totally deterministic computer program.

The problem with an assembler is that it spits out exactly what you push into it. It doesn't modify your code, it doesn't optimise your code, it assumes you know exactly what you are doing and lets you get on with it.

An optimising compiler takes your code, and then twists and turns and tweaks it into something that does what you intend (in most cases). Unless you explicitly flag something as being intentional, it will remove unnecessary operations, optimise, reorder and pipeline operations, eliminate or generate temporary variables, and generally turn your code into something that runs in a fairly close to optimal way. It won't necessarily be perfect, but it should be pretty good.

In most cases, poor performance isn't down to the way the compiler produces code, it's down to bad decisions on the programmer's part. In short, performance issues are usually algorithmic, not down to register allocation or instruction ordering. Bad decisions get made no matter what language you're writing in.

If you want to tweak what comes out of your compiler, that's easy enough to do as well. Well, actually, it's not that easy, especially if we're talking about inline assembler in GCC, but it can be done, and for the very few cases where it's necessary to do it, it can pay off enormously (and inline assembler in GCC gets dealt with by the optimiser)...

[piglet]

Dex.... they need to be properly spelt

What has wheat got to do with it? "Spelt" is seen as a fairly archaic spelling. Most people use the word "spelled" as far as I know.

/pendantry

[tufty]

Dex.... they need to be properly spelt

What has wheat got to do with it? :P "Spelt" is seen as a fairly archaic spelling. Most people use the word "spelled" as far as I know.

I'm a Brit, not a septic :)

[piglet]

I'm a Brit, not a septic

Me too, however it's been a minority spelling here for at least a decade.

*searches*

http://grammarist.com/spelling/spelled-spelt/

OK - there they show it being a lesser used spelling in the UK since around 1985. Over 20 years. Gadzooks!

[arm]

Hi Dex,
cool site on DexBasic. good use of assembler macros to produce a useful language for fast deterministic real time programming. by using macros its easy for users to see how the commands work so they can be modified, enhanced and reused. cant wait to see this project grow and grow !!

Its also worth noting that for fast real time applications where every machine cycle counts using macro code is faster. with macro commands the program code can be located in sequential memory locations without jumps to subroutines. this allows quicker execution with fewer stack operations. the only down side is that you need larger program memory. this is not a problem these days as processor memory is plentiful and very cheap ! also macro assembler languages like DexBasic will use far less program memory than a high level languages like C with all the excess baggage ! faster, smaller more efficient code results...

[mahjongg]

Actually, given enough investigation, you can tell exactly what code a compiler will produce. It is, after all, a totally deterministic computer program.

Yes, you can disassemble the code the compiler produced, so in that sense you can "tell what it produced".

The problem with an assembler is that it spits out exactly what you push into it. It doesn't modify your code, it doesn't optimise your code, it assumes you know exactly what you are doing and lets you get on with it.

In my view that isn't a "problem", its exactly what I want! Even the best optimizing compilers often cannot compete with hand written code.

but there are severe limitations as to what an assembler can do in terms of high level constructs.

Actually, quite literally, there are no limitations on what assembler can do, as in the end everything is written in the instructions of the CPU (assembler). I assume you mean to say that there are limitations in what current macro assemblers can do, then that is a limitation of these pieces of code, not of the concept of macro's in assembly language. It conceptually possible to create macro's that will do anything you want. Especially if you consider you can build new (meta) macro's from existing macro's etc.

One of the reasons that C has become popular is that C stays so near to assembly language that its often described as an "universal assembly language".

And I agree, there isn't a "best way to do anything", it always horses for courses.

In short, performance issues are usually algorithmic,

Very true, but note that algorithms are largely independent of implementation.

[stanjones0net]

It can have all the power of a higher language, but more control than any compiler.
Like forth, it can be its own "operating system", but without the constraints that Forth imposes.

I wasn't aware that Forth had any constraints. Forth is fully extensible, e.g., there is no built in IF THEN ELSE construct. After Forth is started the first task is to extend the language with IF THEN ELSE.

[mahjongg]

I didn't mean procedural constraints, I am well aware that modern FORTH systems can do multitasking and multithreading and can implement traditional filing systems instead of the old block (screens of code) oriented system. I mean that the designer of FORTH has chosen several paradigms for FORTH, its a procedural, stack-oriented, reflective, concatenative language.
Have I mentioned I rather like FORTH? I used to program a bit in it on a TRS-80 model 1.

in contrast, assembly language doesn't prefer any paradigm, or rather it makes possible any paradigm you choose! Its neutral.

But I think we have been railroaded a bit from or original track, "Programming in Basic on bare metal".

I rather enjoy the idea of going back to the roots, a system you turn on and seconds later you can start typing in and running code!

[DexOS]

DexBasic tutorial 2 is available
http://www.dex-os.com/DexBasic/DexBasic.htm

Its only short, as the sun is shining in england and we make the most of it, when we can.

[mahjongg]

Its only short, as the sun is shining in england and we make the most of it, when we can.

Yes here in the Netherlands too, it seems the summer has finally remembered what to do, but is seems short lived.

[stanjones0net]

Thanks everyone for your support and those that do not like the idea thats fine too.
But remember i am not destroying anything, just giving people a new option.

Great work. This is just what I am looking for, just bare metal programming. I will be keeping track of your progress.

[pygmy_giant]

Hi - tuts are looking good.

Something on addressing the GPIO would float my boat.

Also - can I generate a kernel from a binary compiled from any source?

Thanks

[DexOS]

Thanks everyone for input.
@pygmy_giant, Next tut will be on GPIO and yes you would be able to load c++ bin file, but it would need 1 or 2 key things.

[pygmy_giant]

key things - care to share?

[DexOS]

key things - care to share?

Sorry, flat bin file

Code: Select all

org	0x1400000					 ; The load address of this app 20MB
use32							 ; Use 32bit
Lable:	db	'DEX '					 ; Test this to make sure its valid.
dw	ProgramSize-Lable			 ; This is the size of program
b	Start					 ;

End of program

Code: Select all

align 4 			  ; make sure the next bit aligned on a 4 byte boundary
ProgramSize:			  ; this label is so we can work out size of this program
ScreenBuffer:			  ; this label is where our off screen buffer is

Thats just to get it loaded
I will try and make you a demo you can try.

But you may not need it, as i may do a demo of a balancing robot, maybe you could do the bot design and me the software, its up to you.

[pygmy_giant]

thanks

[DexOS]

thanks

See edited post, thanks.

[pygmy_giant]

Thats a generous offer but I haven't even built my bot yet - bits and pieces still ariving in the post and soldering to do etc... I'm hoping to get my son involved this summer holidays as he is with me for 3 weeks... It will probably be a slow burn project...

...I got my I2C data aquisition module in the post today and the first step will be to test the on board pwm / hbridge by running the motors back and forth.

Have got geany running in puppy on the pi and was going to adapt this I2C bit bangy C code: http://www.susa.net/wordpress/2012/06/r ... clock-rtc/

Next task would be to get the opto sensor encoders encoding via readings from GPIO - (tested successfully from bash).

Then to get readings from an I2c gyro / accellerometer

Then to code the balancing algorithm - something like:

1) take readings from gyro and accellerometer and note current wheel torque

2) if gyro's rate of angular change is 0 then the vehicle must be balanced - goto step 5, otherwise...

3) calculate balancing torque as a funtion of angular change and g force vector off-set in order to move wheels under g force vector sum - continue to step 4

4) compare balancing torque and current torque and modify current toque value to approach that of the balancing torque proportional to the difference between them and then return to step 1

----

5) take reading from wheel encoders to determine vehicle velocity

6) if vehicle velocity is the same as the desired velocity then maintain the current wheel torque and return to step 1) otherwise continue to step 7...

7) 'unbalance' by reducing torque if velocity is too slow or increasing torque if velocity is too high (according to safe ammount read from table)

1) goto step 1)


The general control loop would look something like:

1) read clock and store value
2) check gyro / accellerometer / wheel encoders, then do balancing
3) work out next few priorities and add to task cue if tasks less than 3
4) read clock and check against stored value to see how much of 7ms loop time is left
5) do next task in que if there is one and time to do it otherwise goto 1
6) goto 4

I would be happy to do all this with DexBasic but am unsure of I2C and what conditional statements are available and how easy math is.

I was otherwise going to do all this in C(++) and then compile to a flat binary and use kernal.asm to make into a kernal like with Hello.bin in your introduction.

[DexOS]

If i was you, i would start with a simple design and work your way up.
I was thinking something like this to start with.
http://www.societyofrobots.com/member_t ... s/node/185

But the design is up to you, but i will do what i can too help.

[pygmy_giant]

I need all the help I can get. My favourite design is this one: http://www.youtube.com/watch?v=RcNoL3vtXFs

[DexOS]

I need all the help I can get. My favourite design is this one: http://www.youtube.com/watch?v=RcNoL3vtXFs

That looks cool.
I think this would be good. http://www.youtube.com/watch?v=YQgTne7TAGY

[khh]

Actually, given enough investigation, you can tell exactly what code a compiler will produce. It is, after all, a totally deterministic computer program.

Yes, you can disassemble the code the compiler produced, so in that sense you can "tell what it produced".

Most if not all c-compilers support outputting annotated assembly-code, rather than an object file.

The problem with an assembler is that it spits out exactly what you push into it. It doesn't modify your code, it doesn't optimise your code, it assumes you know exactly what you are doing and lets you get on with it.

In my view that isn't a "problem", its exactly what I want! Even the best optimizing compilers often cannot compete with hand written code.

To metaquote someone: "A good assembly programmer produces better assembly than a good c-compiler, but a good c-compiler produces better assembly than an average assembly programmer - and most programmers are below average".

Writing whole projects in assembly just isn't necessary anymore. It's easier to program in C and profile, and just hand-code the absolute critical parts. 20 % of the code uses 80 % of the time, etc.

[pygmy_giant]

Is this really an either - or situation? Can't you have DexBasic convert to assembler and then incorporate that into C code via __asm{...} ? This is an extra golf club in your caddy - no one is saying that you have to use it all the time.