Very Newbie question about INLINE

[TI-994A]

When did that change?. As far as I recall ASM is basically mnemonics representing the raw hex numbers of the machine code to make it easier for us humans to write. I first programmed machine code in the late 70's by writing programs in asm on paper then manual converting the commands into hex from the cpu code list.

Sure asm provides some extras like labels etc but the end result is to all intents & purposes machine code with a 1 to 1 translation of mnemonic to cpu opcode. The exception to the rule is macros & such but this is not a lesson on asm.

Lee

Which makes Assembly a truly low-level language, but still a language nonetheless, that requires translation. Just as you had to "convert the commands into hex", the assembler does the same thing. Technically, nothing's changed.

[fuzzy70]

Machine Code is a language as well, if you have the patience or boredom to memorise the opcodes. Like I said asm is a 1-1 translation of machine code for us mere mortals to understand so your statement of

But ASM is not machine code

is correct up to a point but the line is so thin that the difference between them is negligible.

If you avoid any specifics from a particular Assembler (asm code from one Assembler does not mean it will be translated by another Assembler correctly) like labels etc then the output will be identical to the same code had you entered it in machine code, albeit the asm version is considerably easier to read 

Lee

[Kitty Hello]

I talked to the guy that wrote "Mission Elevator" on the CPC and he did what you said - write the whole game on paper and then typed in the numbers. How insane is that!?
And how would you debug anything?

[bigsofty]

On a related note, I used to work beside a guy used to write his games on a notepad, in hex. His name was Colin Swinborn, he wrote a series of games for the ZX Spectrum called Joe Blade. Pure binary code, no assembler, the only thing he used was a hex editor to turn his notes into an actual file. He even did the animated sprites as binary code in another notepad. He tried to explain to me one day how one of his routines worked but it was gibberish, a page of hex, with hand drawn lines for loops and labels next to certain lines... bonkers but admirable. 

[fuzzy70]

I talked to the guy that wrote "Mission Elevator" on the CPC and he did what you said - write the whole game on paper and then typed in the numbers. How insane is that!?
And how would you debug anything?

Lets just say debugging was more of a "Trial & error" process mainly, multiface type cartridges with monitors helped a lot with regards to debugging allowing you to step through code.

I program pic micro controllers in hex without an assembler but with only 36 odd opcodes it's not really that difficult. I still recognise some z80/6502/68000 hex codes but not the full set from my 8/16bit days. I did not get into PC's really until the 166mmx pentiums, assembly was pretty straight forward on 386/486 but with the additions like mmx & now SSE etc I would not really know where to begin 

Lee


Also with the 8/16bit computers the hardware was a known quantity, whereas PC's where a minefield of hardware combo's which I seriously could not be arsed with 

[Wampus]

On a related note, I used to work beside a guy used to write his games on a notepad, in hex. His name was Colin Swinborn, he wrote a series of games for the ZX Spectrum called Joe Blade. Pure binary code, no assembler, the only thing he used was a hex editor to turn his notes into an actual file. He even did the animated sprites as binary code in another notepad. He tried to explain to me one day how one of his routines worked but it was gibberish, a page of hex, with hand drawn lines for loops and labels next to certain lines... bonkers but admirable. 

[TI-994A]

Machine Code is a language as well ... asm is a 1-1 translation of machine code ... the difference between them is negligible.

Yes, but it's the absolute native command set of the respective processors, and the only codes they could understand and execute. Even Assembly mnemonics would be Greek to them; they wouldn't be able to differentiate a+1 from inc ax, until these are translated into their native opcodes. That's not negligible.

[fuzzy70]

Even Hex for machine code is only used by us as its a lot easier to remember & shorter write down/type than binary, then the joys of machine code being translated to the lowest level of all "microcode" which gladly only the engineers etc that design the cpu's have to deal with. 

Technically machine code is the lowest level available to us mere mortals to use but is not the lowest level that exists in a cpu. At the end of the day the cpu only understands 0's & 1's of which I do not know anyone that writes code in pure binary, bet there is someone somewhere though that does 

What's the difference between 0x40 & INC AX, answer is nothing.  Both are exactly the same & neither are understood by the cpu without being translated by a higher lvl language into binary (which is all the computer understands natively) & then executed/stored.

So I am going to stand by my "negligible" comment but that is my personal opinion, you have yours & I respect that as well.

Lee

[quangdx]

On a related note, I used to work beside a guy used to write his games on a notepad, in hex. His name was Colin Swinborn, he wrote a series of games for the ZX Spectrum called Joe Blade. Pure binary code, no assembler, the only thing he used was a hex editor to turn his notes into an actual file. He even did the animated sprites as binary code in another notepad. He tried to explain to me one day how one of his routines worked but it was gibberish, a page of hex, with hand drawn lines for loops and labels next to certain lines... bonkers but admirable. 

Swinborn was a master when I was a kid, loved the Joe Blade games,
and now that you tell me he wrote everything in hex, from designs on a notepad,
his status has been raised to coding God.

[mentalthink]

@bigsofty

GLBasic, ironically, is actually a very nice platform for learning C++, a little basic wrapper can hide all the usual C project stuff allowing the user to concentrate on the inline or linked C. You can even use the GLB command set as a cross platform API from with the C, to a certain extent.

This it´s really true, before I use GLbasic, I try to learn C++, but nothing works for me... now I think thanks to GLbasic, I can program in diverse lenguajes... the trouble not are the sintaxis, else know how make the things... whit Glbasic it´s for me the better teacher... well at the beggin something are very strange and hard to do it... but pass this stage, how I say, I think I can develop in another lenguajes, only thanks to GLbasic...
 
I it

[TI-994A]

Even Hex for machine code is only used by us as its a lot easier to remember & shorter write down/type than binary, then the joys of machine code being translated to the lowest level of all "microcode" which gladly only the engineers etc that design the cpu's have to deal with. 

Technically machine code is the lowest level available to us mere mortals to use but is not the lowest level that exists in a cpu. At the end of the day the cpu only understands 0's & 1's of which I do not know anyone that writes code in pure binary, bet there is someone somewhere though that does 

What's the difference between 0x40 & INC AX, answer is nothing.  Both are exactly the same & neither are understood by the cpu without being translated by a higher lvl language into binary (which is all the computer understands natively) & then executed/stored.

So I am going to stand by my "negligible" comment but that is my personal opinion, you have yours & I respect that as well.

Lee

First of all, microcode is the very part of the processor that we are trying to program using machine code. If you want to go lower than that, you'd have to manually apply the electrical voltages to the transistors yourself. So, being mere mortals, let's get back to reality.

Machine code is binary, and only binary. The hexadecimal format is not used as a mnemonic code because it's easier to remember, but because the computers we usually work on do not have the ability to display real binary representation in zeroes and ones. Furthermore, these hexadecimal values need no further conversion, because they already represent the binary values in their bits; for example, 0xC has a binary value of 1100, 0xAA has a binary value of 10101010, and 0xAFC has a binary value of 101011111100. That's not a conversion, but the direct binary bit values of the hexadecimal bytes, which is the machine code in zeroes and ones.

Even if you were to input binary code directly, the sequences that you edit on the screen wouldn't be the real binary values. In fact, it would take more effort for an editor to display binary representations on the screen, having to convert them back and forth between displayable sequences of zeroes and ones, and usable/readable values, be they decimal, octal, or even hexadecimal.

And to your question, "What's the difference between 0x40 & INC AX?", the answer is plenty. Firstly, inc ax is an Assembly language instruction that requires compilation before the processor can understand it, while 0x40 is only a hexadecimal value. However, if this hexadecimal value is used in the context of a high level language, it would have to be compiled before the processor can understand it. But, on the other hand, if it is used in the context of a raw hex-editor, then the processor would readily be able to understand its binary bit values without any conversion or compilation.

With all due respect, this is not a matter of opinion, but rather one of fact. Assembly language is not machine code, and since one is readily understandable by the processor, and the other needs to be compiled before it is, clearly makes a big difference. Far from negligible.

[fuzzy70]

Seriously am not going to bother after this but just to correct a couple of points

• At no stage did I say that hex is a mnemonic but was used by us humans as easier to remember.
• I did state that the cpu only understands 0's & 1's
• Assembly does not require compilation because the mnemonics directly relate to the machine code instruction so it gets translated. Compilation occurs on high level languages not low
• I also did not state machine code is assembly or vice versa, just the negligible part should was referring to  the fact that they both produce the same end result because of the 1-1 translation. C/BASIC/PASCAL etc do not provide that 1-1 tanslation
• Also I did state that that 0x40 & INC AX,

  & neither are understood by the cpu without being translated by a higher lvl language

  I could have stated hex editor as well but technically that translates the users input of 0x40 to binary

I am fully aware also of what the binary value of hex equals so to me your explanation was both pedantic & rude as far as I am concerned.

Lee

[TI-994A]

For a moment, I really thought that we were having a healthy discussion.

At no stage did I say that hex is a mnemonic but was used by us humans as easier to remember.

But, that's what mnemonic literally means; easy to remember.

Assembly does not require compilation because the mnemonics directly relate to the machine code instruction so it gets translated. Compilation occurs on high level languages not low

And this is not pedantry? The terms compile, convert, and even translate, are semantically interchangeable without losing its intended meaning; however, if you really want to be a stickler for inconsequentials, then the accurate term would be to assemble.

I also did not state machine code is assembly or vice versa, just the negligible part should was referring to  the fact that they both produce the same end result because of the 1-1 translation.

Not always one-to-one, not before it's assembled, and definitely not negligible.

I could have stated hex editor as well but technically that translates the users input of 0x40 to binary

No, it doesn't. Hex editors handle raw data, and the hexadecimal values are read & written byte for byte; unless you have some revolutionarily new bitstream editor.

I am fully aware also of what the binary value of hex equals so to me your explanation was both pedantic & rude as far as I am concerned.

From your clear lack on the subject, your grasp wasn't apparent. And you still didn't correct any points.

[fuzzy70]

Your ability to always have the last word on every post you make is uncanny as was expected & which part of contradicting my every comment is classed as a healthy discussion 

Also your ability to totally misread some of my comments astounds me as in

I could have stated hex editor as well but technically that translates the users input of 0x40 to binary

No, it doesn't. Hex editors handle raw data, and the hexadecimal values are read & written byte for byte; unless you have some revolutionarily new bitstream editor.

keywords there are translates the users input no mention at all of how hex editors handle raw data. Like you said numerous times a cpu works on binary data so the hex editor (either the program itself, a library it uses or whatever) has to translate the users hex input in binary for storage somewhere like ram or a file seeing as not only cpu's but ram etc are also a sequence of 0's & 1's. In fact the chain is considerably longer but why should I write a huge paragraph to explain something that is encapsulated easily into 1 line.

Still, I am going to take my clear lack of the subject away with me, read more books & articles then arrive back where I started.

Please help you self to ripping this post apart like my others as I am sure you will

Lee

[TI-994A]

the hex editor (either the program itself, a library it uses or whatever) has to translate the users hex input in binary for storage somewhere like ram or a file seeing as not only cpu's but ram etc are also a sequence of 0's & 1's. In fact the chain is considerably longer...

No, in fact the chain is short and simple; all file I/O is handled by the operating system. Even Assembly facilitates file handling via simple and direct calls to system interrupt 21h (3Dh, 3Fh, 40h, 3Eh), which read & write values byte for byte; no conversions, no libraries. I'm surprised you didn't know that.

Still, I am going to take my clear lack of the subject away with me, read more books & articles then arrive back where I started.

Hope I didn't misread you.