@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.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
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.
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.
Ostendo ignarus addo scientia.
Re: Programming in Basic on Bare Metal Tutorial 1
Quite right.DexOS wrote: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.
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.mahjongg wrote: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".
Actually, given enough investigation, you can tell exactly what code a compiler will produce. It is, after all, a totally deterministic computer program.mahjongg wrote: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.
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)...
Re: Programming in Basic on Bare Metal Tutorial 1
What has wheat got to do with it?tufty wrote:Dex.... they need to be properly spelt

/pendantry
Re: Programming in Basic on Bare Metal Tutorial 1
I'm a Brit, not a septic :)piglet wrote: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.tufty wrote:Dex.... they need to be properly spelt
Re: Programming in Basic on Bare Metal Tutorial 1
Me too, however it's been a minority spelling here for at least a decade.tufty wrote:I'm a Brit, not a septic
*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!
Re: Programming in Basic on Bare Metal Tutorial 1
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...ginkgo wrote: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 !!
- mahjongg
- Forum Moderator
- Posts: 13675
- Joined: Sun Mar 11, 2012 12:19 am
- Location: South Holland, The Netherlands
Re: Programming in Basic on Bare Metal Tutorial 1
Yes, you can disassemble the code the compiler produced, so in that sense you can "tell what it produced".Actually, given enough investigation, you can tell exactly what code a compiler will produce. It is, after all, a totally deterministic computer program.
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.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.
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.but there are severe limitations as to what an assembler can do in terms of high level constructs.
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.
Very true, but note that algorithms are largely independent of implementation.In short, performance issues are usually algorithmic,
- stanjones0net
- Posts: 3
- Joined: Fri Jun 15, 2012 2:24 pm
Re: Programming in Basic on Bare Metal Tutorial 1
mahjongg wrote: 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
- Forum Moderator
- Posts: 13675
- Joined: Sun Mar 11, 2012 12:19 am
- Location: South Holland, The Netherlands
Re: Programming in Basic on Bare Metal Tutorial 1
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!
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!
Re: Programming in Basic on Bare Metal Tutorial 1
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.
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.
Batteries not included, Some assembly required.
- mahjongg
- Forum Moderator
- Posts: 13675
- Joined: Sun Mar 11, 2012 12:19 am
- Location: South Holland, The Netherlands
Re: Programming in Basic on Bare Metal Tutorial 1
Yes here in the Netherlands too, it seems the summer has finally remembered what to do, but is seems short lived.Its only short, as the sun is shining in england and we make the most of it, when we can.
- stanjones0net
- Posts: 3
- Joined: Fri Jun 15, 2012 2:24 pm
Re: Programming in Basic on Bare Metal Tutorial 1
Great work. This is just what I am looking for, just bare metal programming. I will be keeping track of your progress.DexOS wrote: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.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
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
Something on addressing the GPIO would float my boat.
Also - can I generate a kernel from a binary compiled from any source?
Thanks
Ostendo ignarus addo scientia.
Re: Programming in Basic on Bare Metal Tutorial 1
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, 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.
Batteries not included, Some assembly required.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
key things - care to share?
Ostendo ignarus addo scientia.
Re: Programming in Basic on Bare Metal Tutorial 1
Sorry, flat bin filepygmy_giant wrote:key things - care to share?
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 ;
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
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.
Last edited by DexOS on Thu Jul 26, 2012 5:14 pm, edited 1 time in total.
Batteries not included, Some assembly required.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
See edited post, thanks.pygmy_giant wrote:thanks
Batteries not included, Some assembly required.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
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.
...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.
Ostendo ignarus addo scientia.
Re: Programming in Basic on Bare Metal Tutorial 1
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.
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.
Batteries not included, Some assembly required.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
I need all the help I can get. My favourite design is this one: http://www.youtube.com/watch?v=RcNoL3vtXFs
Re: Programming in Basic on Bare Metal Tutorial 1
That looks cool.pygmy_giant wrote:I need all the help I can get. My favourite design is this one: http://www.youtube.com/watch?v=RcNoL3vtXFs
I think this would be good. http://www.youtube.com/watch?v=YQgTne7TAGY
Batteries not included, Some assembly required.
Re: Programming in Basic on Bare Metal Tutorial 1
Most if not all c-compilers support outputting annotated assembly-code, rather than an object file.mahjongg wrote:Yes, you can disassemble the code the compiler produced, so in that sense you can "tell what it produced".Actually, given enough investigation, you can tell exactly what code a compiler will produce. It is, after all, a totally deterministic computer program.
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".mahjongg wrote: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.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.
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.
-
- Posts: 1562
- Joined: Sun Mar 04, 2012 12:49 am
Re: Programming in Basic on Bare Metal Tutorial 1
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.