Forums

I'm sorry but I forgot all about how Segments and offsets work. I know that a segment is a block of memory and an offset gives access to what's inside those segments. Something like this...

mov ax, A000
mov es, ax
mov di, 200
mov [es:di],15

What made me think about this stuff is because I was reading through a 68000 manual and it's method for accessing memory is similar to that of the 80x86's. I want to make sure that I have a good understanding of this segment/offset stuff before I go venture into any more chips like the 68000 or the SH2.

Chris :o)

Ahh, 16-bit segments. My god am I glad to be rid of that stuff.

The idea is this. Intel engineers wanted to be able to address more than 64k of RAM (since you can only addres 64K with a 16bit address). But, they figured, 32-bits (4 gigs) was an awefully unnecessary jump up, so they came across a compromise that suceeded in massivley limiting a 32-bit address space to only be able to hold 640k of RAM.

Basically, each segment can hold 64k of RAM, but they're on 16-byte (10h) boundaries. For example:

Seg:OFS (all values in hex)
0000:0005 would be an absolute address of 00005h.
0001:0005 would be an absolute address of 00015h.
0030:0020 would be an absolute address of 00320h.

Basically the formula for converting seg:ofs format into a linear address is (seg * 10h) + ofs.

Thusly the absolute address of the video buffer (at A000:0000) is just A0000h (one more zero at the end).

I don't know whether or not the 68000 also uses segments on 16-byte offsets or not. I've seen genesis roms larger than one megabyte, so it may not; but in coordination with bank switching, it could.

The only real purpose of the segment:offset format is simply so that you can still use 16-bit values for memory addresses, since in general these were all 16bit cpus.

- vecna

Quote

> I'm sorry but I forgot all about how Segments and offsets work. I know that a segment is a block of memory and an offset gives access to what's inside those segments. Something like this...

> mov ax, A000
> mov es, ax
> mov di, 200
> mov [es:di],15

it's better left forgotten.
The idea behind it is that 'es' doesn't point to $a000, but rather, to $a0000. But $a0000 is too large a number to fit in a 16-bit registers. Thus, es holds the top 16 bits of the 20 bit address. The bottom four bits are always assumed to be zero.
The di register is used with the es register to construct the full address of memory that was to be written to or fetched.
This was intel's hairbrained scheme to get a greater-than-16bit address space (64k) without using registers greater than 16 bits in size. This way, the 8088/8086 chips could address a whopping one megabyte of memory (ram, rom, device i/o, etc). In the classic PC architecture, the top 384k was tied up in bios, video ram, device io, and other things, leaving 640k for memory, hence the old 640k limit for real-mode systems (orginally)

Motorola was lots smarter than intel. It's 68000 line of processors had all 32-bit registers (and lots of them, too). The programmer had the option of treating registers as 16 bit or 32 bit values... treating them as 32-bit values meant slower executing times on the 16-bit versions of the processors (the 68000 and 68010), but it was handy having that option.

The 68000 uses a flat memory model, just like the 286+ processors use when they're not in 'real' mode (which is always, when running any remotely modern operating system... or even in most dos programs these days. The 68000 has a 24-bit addressing space, which allows for accessing up to 16 megabytes). However, the address registers of the 68000 are 32-bits wide, so the top 8 bits of the address are ignored (masked off) when the address registers are used to fetch data from memory). The 68020 and above are fully 32 bit, and include a 32bit addressable space. That just means that every bit in the address registers is considered relevant, thus bringing the addressable space to four gigabytes. Later models include integrated FPU's, memory management units, and general design updates. There is no use of 'segmenting' in any of these chips, but using registers as offset values for pointers is certainly common practice (and a very useful feature).

I'm fairly certain any modern processor uses a flat memory model, also. There are some odd microcontrollers that use a variety of memory addressing systems, though.

So address space is the amount of bits that can be transfered into and out of memory? Like, the 6502 has an 8-bit address space, while the Z80 has a 16-bit address space and the 68000 has a 24-bit address space? And why do these Chip manufactures change their damn minds so much? One minute, they're using this type of archetecture, the next their changing to that one, before you know it they've created an entirely new one. Why not just keep things standard? Anyway, ever since I found this 68000 cross-assembler and these 68000 .PDF files from motorola.com, it's turned me on to them. Their archetecture seems fairly straight forward, just like the 6502s and the Z80s. I was always intimidated of them because I figured they emulated the mighty Sega Genesis and the Neo Geo but their really not that big of a deal. They have bigger registers, better ways of accessing memory, and faster execution times. Big deal. But the instruction syntax is kinda different. Like in Z80 if you wanted to send data to a register, you would do it like this...




LD B, F2

In 68000 it's like this...




MOVE.B $F2, D0

But anyway, back to the address stuff.

Chris :o)

Quote

> So address space is the amount of bits that can be transfered into and out of memory? Like, the 6502 has an 8-bit address space, while the Z80 has a 16-bit address space and the 68000 has a 24-bit address space?

No, address space is the amount of distinct memory locations that the processor can recognize. A processor with an 8 bit addressable space would only have 256 bytes of memory. Some microcontrollers have such tiny address spaces, but no microprocessors do. (i -hope-)
Most CPU's have at least a 16-bit address space (like the 6502 and z80).
The Z80, for instance, uses two-byte registers (HL, DE, BC, IX, IY) to point to data. That gives you 65536 distinct bytes of memory. If you need any more space than that, you have to resort to using bank switching schemes. Bank switching is not a built in feature of the cpu, rather it's a bit of trickery in the data bus and cartridge interface.

(for the record, in the above, when I say 'memory', I don't necessarily mean RAM, but also ROM, device interfaces, RAM/ROM mirrors, or nothing, depending on the hardware implementation. The z80 itself doesn't care what sort of 'memory' it's interfacing with, it just sends read and write requests over the data bus).

Quote

> And why do these Chip manufactures change their damn minds so much? One minute, they're using this type of archetecture, the next their changing to that one, before you know it they've created an entirely new one. Why not just keep things standard?

PROGRESS.
What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually).

Quote

> Anyway, ever since I found this 68000 cross-assembler and these 68000 .PDF files from motorola.com, it's turned me on to them. Their archetecture seems fairly straight forward, just like the 6502s and the Z80s.

Yes, I cut my teeth on 16-bit assembly with the 68000 on my amigas, and I've always liked them a lot. It was quite a shock to move to intel assembly later on, with all it's weird quirks, limited amount of registers, registers tied down to certain inherit functions, etc. I still don't like it, but it's the law of the land these days.

Quote

> I was always intimidated of them because I figured they emulated the mighty Sega Genesis and the Neo Geo but their really not that big of a deal. They have bigger registers, better ways of accessing memory, and faster execution times. Big deal.

Just an all-around sensible chip.

Quote

> But the instruction syntax is kinda different. Like in Z80 if you wanted to send data to a register, you would do it like this...

I've always thought the source,destination notation made much more sense. It more closely immitates natural english speech, after all. I'd be more likely to think or say: "Move the number 3 into register d0" than "Move into register d0, the number 3", etc.

Of course, I started my assembly language career with 6502 assembly, followed by 68000, which were both source, destination.
I also think hex notation with a trailing h is just repugnant.

GNU C/DJGPP's assembly syntax is enough like Motorola Syntax that I don't feel so uncomfortable with it.

Quote

> Bank switching is not a built in feature of the cpu, rather it's a bit of trickery in the data bus and cartridge interface.

For the record, some CPUs (the 6280 or the Z180 for example) actually do have bankswitching in the CPU. And you can view an MMU as a special case of a bankswitcher, which would mean that for all x86 where x >= 3 the CPU has a bankswitcher.

Quote

> PROGRESS.
> What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually).

I don't suppose you'd be willing to let that go real cheap? ^_^

Quote

> Yes, I cut my teeth on 16-bit assembly with the 68000 on my amigas, and I've always liked them a lot. It was quite a shock to move to intel assembly later on, with all it's weird quirks, limited amount of registers, registers tied down to certain inherit functions, etc. I still don't like it, but it's the law of the land these days.

Well, I'm taking a good long look at the possibility of switching lands. Say, a MISC chip?

Quote

> I've always thought the source,destination notation made much more sense. It more closely immitates natural english speech, after all. I'd be more likely to think or say: "Move the number 3 into register d0" than "Move into register d0, the number 3", etc.

I've been thinking that it should be either source, destination, mnemonic or destination, source, mnemonic, but I'm not sure which. ^_^

Quote

> Of course, I started my assembly language career with 6502 assembly, followed by 68000, which were both source, destination.
> I also think hex notation with a trailing h is just repugnant.

Objection. 6502 ASM only ever uses one operand. You never see source and destination in the same instruction, so the relative order doesn't come into play.

And I agree about the trailing h notation. To represent a number beginning with a digit greater than 9, you have to prefix it with a 0. It's also harder to write a parser for.

Quote

> GNU C/DJGPP's assembly syntax is enough like Motorola Syntax that I don't feel so uncomfortable with it.

Of course, it is also enough like a loaded gun without a safety that you can easily get it to generate really stupid code without it warning you (move a byte register into a long? no problem. push a word register without specifying a size on the instruction? I hope you don't mind a 32-bit instruction, etc.).

--Nyef

Now I see. It's not that the 68000 is the mighty backwards chip, but it's the other chips that are mighty and backwards! The 68000 is simple, straight-forward and powerful! I really like it's syntax. There's no mistake in what you're doing. If I want to move a byte, I type:




move.b

If I want to move a word, I do so like this:
move.w
And all the codes are in an english-like pattern. I haven't found anything backwards about it. Things make a lot more sense when their written in a pattern that I can read...




code  value,register


---------------------


move.w $4000,d0

My final question is does the 68000 store it's bytes in Little Endian or Big Indian? Like this, 76543210? Or this? 01234567. Cause, if it did it like this, 01234567, in a normal, readable way, I'm going to shout!

Chris :o)

Quote

> For the record, some CPUs (the 6280 or the Z180 for example) actually do have bankswitching in the CPU. And you can view an MMU as a special case of a bankswitcher, which would mean that for all x86 where x >= 3 the CPU has a bankswitcher.

In a sense, yes.
Interesting processor notation, I'd just say '386's and above'.

Quote

> > PROGRESS.
> > What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually).

> I don't suppose you'd be willing to let that go real cheap? ^_^

Sure! I'll sell it to you for only $2000 -that's $500 less than I paid for it!

Quote

> Well, I'm taking a good long look at the possibility of switching lands. Say, a MISC chip?

Okay.
"A MISC chip?"
Satisfied?

Quote

> I've been thinking that it should be either source, destination, mnemonic or destination, source, mnemonic, but I'm not sure which. ^_^

can't figure that logic. You must be canadian.

Quote

> Objection. 6502 ASM only ever uses one operand. You never see source and destination in the same instruction, so the relative order doesn't come into play.

Yes it does, when the source and destination are coded into the mnemonic: Does TAX transfer X to the accumulator? No, it transfers the accumulator to X.
The occurances are rare, but it was enough to set a precident.

Quote

> And I agree about the trailing h notation. To represent a number beginning with a digit greater than 9, you have to prefix it with a 0. It's also harder to write a parser for.

I can think in hex, but not martian.

Quote

> > GNU C/DJGPP's assembly syntax is enough like Motorola Syntax that I don't feel so uncomfortable with it.

> Of course, it is also enough like a loaded gun without a safety that you can easily get it to generate really stupid code without it warning you (move a byte register into a long? no problem. push a word register without specifying a size on the instruction? I hope you don't mind a 32-bit instruction, etc.).

I always specified size in the instruction (I picked up that habit in the 68000 days, at the advice of my assembly book). So I haven't had many problems.

Quote

> Now I see. It's not that the 68000 is the mighty backwards chip, but it's the other chips that are mighty and backwards! The 68000 is simple, straight-forward and powerful! I really like it's syntax. There's no mistake in what you're doing. If I want to move a byte, I type:
> > move.b >
> If I want to move a word, I do so like this:
> move.w
> And all the codes are in an english-like pattern. I haven't found anything backwards about it. Things make a lot more sense when their written in a pattern that I can read...

I do like the syntax. Of course, theorerically, you could use motorola syntax in a PC assembler, or Intel syntax ina 68000 assembler. In fact, I think there was a motorola syntax assembler for the x86, though I believe it only supported real mode.

You'll also find that it's syntax for using register offsets is much more readable that intel's.

Quote

> > code value,register > --------------------- > move.w $4000,d0 >
> My final question is does the 68000 store it's bytes in Little Endian or Big Indian? Like this, 76543210? Or this? 01234567. Cause, if it did it like this, 01234567, in a normal, readable way, I'm going to shout!

It's big endian, knock yourself out.
I happen to see that there are pros and cons in each word format, but I still prefer big endian, just because that's why I got used to first.

Quote

> Interesting processor notation, I'd just say '386's and above'.

Yes, you probably would. :-P

Quote

> > > PROGRESS.
> > > What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually).

> > I don't suppose you'd be willing to let that go real cheap? ^_^

> Sure! I'll sell it to you for only $2000 -that's $500 less than I paid for it!

Not exactly my definition of "real cheap". I think I'll wait for the new amiga or something.

Quote

> > I've been thinking that it should be either source, destination, mnemonic or destination, source, mnemonic, but I'm not sure which. ^_^

> can't figure that logic. You must be canadian.

I can't follow your logic there. Ah, well. I'll just finish writing this assembler and then inflict the notation on all the normal, right-thinking people around here. ^_^

And no, I'm not canadian.

Quote

> > Objection. 6502 ASM only ever uses one operand. You never see source and destination in the same instruction, so the relative order doesn't come into play.

> Yes it does, when the source and destination are coded into the mnemonic: Does TAX transfer X to the accumulator? No, it transfers the accumulator to X.
> The occurances are rare, but it was enough to set a precident.

No, those are implied addressing mode instructions, so they don't really have operands. If it were "A X LD," or "mov a, x" you might have a case, but it isn't, so you don't.

Quote

> I can think in hex, but not martian.

That would have been funnier if you had said "I grok hex, but not martian". Exactly why is left as an excersize for the reader. ^_^

Quote

> > Of course, it is also enough like a loaded gun without a safety that you can easily get it to generate really stupid code without it warning you (move a byte register into a long? no problem. push a word register without specifying a size on the instruction? I hope you don't mind a 32-bit instruction, etc.).

> I always specified size in the instruction (I picked up that habit in the 68000 days, at the advice of my assembly book). So I haven't had many problems.

Well, I started specifying sizr in the instruction after I realized that GNU as had no protection at all. I'm not saying I have had problems, just that it's annoying.

--Nyef

Quote

> > > I don't suppose you'd be willing to let that go real cheap? ^_^

> > Sure! I'll sell it to you for only $2000 -that's $500 less than I paid for it!

> Not exactly my definition of "real cheap". I think I'll wait for the new amiga or something.

(hah). Cheap bastard, I was going to throw in an emplant board for free, too.

Quote

> I can't follow your logic there. Ah, well. I'll just finish writing this assembler and then inflict the notation on all the normal, right-thinking people around here. ^_^

japanese speakers will probably like it.

Quote

> And no, I'm not canadian.

i don't know about that.

Quote

> > Yes it does, when the source and destination are coded into the mnemonic: Does TAX transfer X to the accumulator? No, it transfers the accumulator to X.
> > The occurances are rare, but it was enough to set a precident.

> No, those are implied addressing mode instructions, so they don't really have operands. If it were "A X LD," or "mov a, x" you might have a case, but it isn't, so you don't.

Yes I do. The choice to roll the operands into the mneumonic was completely arbitrary. Zilog could just have well called ld b,c something like 'tcb'.. it is a one byte instruction after all.
The 'tax' instructions has two operands, and they're not 'implied' but clearly specified in the mnemonic.

Quote

> That would have been funnier if you had said "I grok hex, but not martian". Exactly why is left as an excersize for the reader. ^_^

Naw, the whole 'grok' business is overused.
Though I suppose with the whole martian thing...
hell with it.

Quote

> Well, I started specifying sizr in the instruction after I realized that GNU as had no protection at all. I'm not saying I have had problems, just that it's annoying.

It made a man out of you.

Quote

> > I can't follow your logic there. Ah, well. I'll just finish writing this assembler and then inflict the notation on all the normal, right-thinking people around here. ^_^

> japanese speakers will probably like it.

Cool! Now I'll definately inflict it on the people here. ^_^

Quote

> Yes I do. The choice to roll the operands into the mneumonic was completely arbitrary. Zilog could just have well called ld b,c something like 'tcb'.. it is a one byte instruction after all.

No, if it's arbitrary it implies that there isn't a tradeoff involved, and with the Z80 there is a definate tradeoff between assembler parser complexity and the number of mnemonics required for the 8-bit load group.

Quote

> The 'tax' instructions has two operands, and they're not 'implied' but clearly specified in the mnemonic.

If they are specified in the mnemonic, they are impied. They could have easily called it something silly like LSR (Load Stack Register, see also the LMSW instruction on the x86, later "move cr0, reg" (stupid "destination, source notation")), or do the Z80 thing and have something like "LD R, A", even though that's the only way to set the R register on the Z80.

Quote

> > Well, I started specifying sizr in the instruction after I realized that GNU as had no protection at all. I'm not saying I have had problems, just that it's annoying.

> It made a man out of you.

No, that was done by using packed structures in gcc to hold x86 machine code to do stuff when a return statement is executed in the middle of a procedure (and yes, this was implemented by rewriting the return address on the stack). Then there were the times I used packed structs of machine code and memcpy() to create procedures at runtime... Scared yet? ^_^

--Nyef

Ahhhhh!!!!! Yeah!!! Sweet!!!

Chris :o)!!!

Author	Message
Consolemu Guest	Segments: Offsets...Again Posted: Sun Apr 16, 2000 9:47 pm
Consolemu Guest	I'm sorry but I forgot all about how Segments and offsets work. I know that a segment is a block of memory and an offset gives access to what's inside those segments. Something like this... mov ax, A000 mov es, ax mov di, 200 mov [es:di],15 What made me think about this stuff is because I was reading through a 68000 manual and it's method for accessing memory is similar to that of the 80x86's. I want to make sure that I have a good understanding of this segment/offset stuff before I go venture into any more chips like the 68000 or the SH2. Chris :o)

vecna Guest	Posted: Sun Apr 16, 2000 10:10 pm
vecna Guest	Ahh, 16-bit segments. My god am I glad to be rid of that stuff. The idea is this. Intel engineers wanted to be able to address more than 64k of RAM (since you can only addres 64K with a 16bit address). But, they figured, 32-bits (4 gigs) was an awefully unnecessary jump up, so they came across a compromise that suceeded in massivley limiting a 32-bit address space to only be able to hold 640k of RAM. Basically, each segment can hold 64k of RAM, but they're on 16-byte (10h) boundaries. For example: Seg:OFS (all values in hex) 0000:0005 would be an absolute address of 00005h. 0001:0005 would be an absolute address of 00015h. 0030:0020 would be an absolute address of 00320h. Basically the formula for converting seg:ofs format into a linear address is (seg * 10h) + ofs. Thusly the absolute address of the video buffer (at A000:0000) is just A0000h (one more zero at the end). I don't know whether or not the 68000 also uses segments on 16-byte offsets or not. I've seen genesis roms larger than one megabyte, so it may not; but in coordination with bank switching, it could. The only real purpose of the segment:offset format is simply so that you can still use 16-bit values for memory addresses, since in general these were all 16bit cpus. - vecna

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Sun Apr 16, 2000 11:09 pm
	Quote > I'm sorry but I forgot all about how Segments and offsets work. I know that a segment is a block of memory and an offset gives access to what's inside those segments. Something like this... > mov ax, A000 > mov es, ax > mov di, 200 > mov [es:di],15 it's better left forgotten. The idea behind it is that 'es' doesn't point to $a000, but rather, to $a0000. But $a0000 is too large a number to fit in a 16-bit registers. Thus, es holds the top 16 bits of the 20 bit address. The bottom four bits are always assumed to be zero. The di register is used with the es register to construct the full address of memory that was to be written to or fetched. This was intel's hairbrained scheme to get a greater-than-16bit address space (64k) without using registers greater than 16 bits in size. This way, the 8088/8086 chips could address a whopping one megabyte of memory (ram, rom, device i/o, etc). In the classic PC architecture, the top 384k was tied up in bios, video ram, device io, and other things, leaving 640k for memory, hence the old 640k limit for real-mode systems (orginally) Motorola was lots smarter than intel. It's 68000 line of processors had all 32-bit registers (and lots of them, too). The programmer had the option of treating registers as 16 bit or 32 bit values... treating them as 32-bit values meant slower executing times on the 16-bit versions of the processors (the 68000 and 68010), but it was handy having that option. The 68000 uses a flat memory model, just like the 286+ processors use when they're not in 'real' mode (which is always, when running any remotely modern operating system... or even in most dos programs these days. The 68000 has a 24-bit addressing space, which allows for accessing up to 16 megabytes). However, the address registers of the 68000 are 32-bits wide, so the top 8 bits of the address are ignored (masked off) when the address registers are used to fetch data from memory). The 68020 and above are fully 32 bit, and include a 32bit addressable space. That just means that every bit in the address registers is considered relevant, thus bringing the addressable space to four gigabytes. Later models include integrated FPU's, memory management units, and general design updates. There is no use of 'segmenting' in any of these chips, but using registers as offset values for pointers is certainly common practice (and a very useful feature). I'm fairly certain any modern processor uses a flat memory model, also. There are some odd microcontrollers that use a variety of memory addressing systems, though.

Consolemu Guest	Wait a minute... Posted: Mon Apr 17, 2000 2:40 am
Consolemu Guest	So address space is the amount of bits that can be transfered into and out of memory? Like, the 6502 has an 8-bit address space, while the Z80 has a 16-bit address space and the 68000 has a 24-bit address space? And why do these Chip manufactures change their damn minds so much? One minute, they're using this type of archetecture, the next their changing to that one, before you know it they've created an entirely new one. Why not just keep things standard? Anyway, ever since I found this 68000 cross-assembler and these 68000 .PDF files from motorola.com, it's turned me on to them. Their archetecture seems fairly straight forward, just like the 6502s and the Z80s. I was always intimidated of them because I figured they emulated the mighty Sega Genesis and the Neo Geo but their really not that big of a deal. They have bigger registers, better ways of accessing memory, and faster execution times. Big deal. But the instruction syntax is kinda different. Like in Z80 if you wanted to send data to a register, you would do it like this... `LD B, F2` In 68000 it's like this... `MOVE.B $F2, D0` But anyway, back to the address stuff. Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Wait a minute... Posted: Mon Apr 17, 2000 3:05 am
	Quote > So address space is the amount of bits that can be transfered into and out of memory? Like, the 6502 has an 8-bit address space, while the Z80 has a 16-bit address space and the 68000 has a 24-bit address space? No, address space is the amount of distinct memory locations that the processor can recognize. A processor with an 8 bit addressable space would only have 256 bytes of memory. Some microcontrollers have such tiny address spaces, but no microprocessors do. (i -hope-) Most CPU's have at least a 16-bit address space (like the 6502 and z80). The Z80, for instance, uses two-byte registers (HL, DE, BC, IX, IY) to point to data. That gives you 65536 distinct bytes of memory. If you need any more space than that, you have to resort to using bank switching schemes. Bank switching is not a built in feature of the cpu, rather it's a bit of trickery in the data bus and cartridge interface. (for the record, in the above, when I say 'memory', I don't necessarily mean RAM, but also ROM, device interfaces, RAM/ROM mirrors, or nothing, depending on the hardware implementation. The z80 itself doesn't care what sort of 'memory' it's interfacing with, it just sends read and write requests over the data bus). Quote > And why do these Chip manufactures change their damn minds so much? One minute, they're using this type of archetecture, the next their changing to that one, before you know it they've created an entirely new one. Why not just keep things standard? PROGRESS. What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually). Quote > Anyway, ever since I found this 68000 cross-assembler and these 68000 .PDF files from motorola.com, it's turned me on to them. Their archetecture seems fairly straight forward, just like the 6502s and the Z80s. Yes, I cut my teeth on 16-bit assembly with the 68000 on my amigas, and I've always liked them a lot. It was quite a shock to move to intel assembly later on, with all it's weird quirks, limited amount of registers, registers tied down to certain inherit functions, etc. I still don't like it, but it's the law of the land these days. Quote > I was always intimidated of them because I figured they emulated the mighty Sega Genesis and the Neo Geo but their really not that big of a deal. They have bigger registers, better ways of accessing memory, and faster execution times. Big deal. Just an all-around sensible chip. Quote > But the instruction syntax is kinda different. Like in Z80 if you wanted to send data to a register, you would do it like this... I've always thought the source,destination notation made much more sense. It more closely immitates natural english speech, after all. I'd be more likely to think or say: "Move the number 3 into register d0" than "Move into register d0, the number 3", etc. Of course, I started my assembly language career with 6502 assembly, followed by 68000, which were both source, destination. I also think hex notation with a trailing h is just repugnant. GNU C/DJGPP's assembly syntax is enough like Motorola Syntax that I don't feel so uncomfortable with it.

Nyef Guest	Re: Wait a minute... Posted: Mon Apr 17, 2000 2:01 pm
Nyef Guest	Quote > Bank switching is not a built in feature of the cpu, rather it's a bit of trickery in the data bus and cartridge interface. For the record, some CPUs (the 6280 or the Z180 for example) actually do have bankswitching in the CPU. And you can view an MMU as a special case of a bankswitcher, which would mean that for all x86 where x >= 3 the CPU has a bankswitcher. Quote > PROGRESS. > What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually). I don't suppose you'd be willing to let that go real cheap? ^_^ Quote > Yes, I cut my teeth on 16-bit assembly with the 68000 on my amigas, and I've always liked them a lot. It was quite a shock to move to intel assembly later on, with all it's weird quirks, limited amount of registers, registers tied down to certain inherit functions, etc. I still don't like it, but it's the law of the land these days. Well, I'm taking a good long look at the possibility of switching lands. Say, a MISC chip? Quote > I've always thought the source,destination notation made much more sense. It more closely immitates natural english speech, after all. I'd be more likely to think or say: "Move the number 3 into register d0" than "Move into register d0, the number 3", etc. I've been thinking that it should be either source, destination, mnemonic or destination, source, mnemonic, but I'm not sure which. ^_^ Quote > Of course, I started my assembly language career with 6502 assembly, followed by 68000, which were both source, destination. > I also think hex notation with a trailing h is just repugnant. Objection. 6502 ASM only ever uses one operand. You never see source and destination in the same instruction, so the relative order doesn't come into play. And I agree about the trailing h notation. To represent a number beginning with a digit greater than 9, you have to prefix it with a 0. It's also harder to write a parser for. Quote > GNU C/DJGPP's assembly syntax is enough like Motorola Syntax that I don't feel so uncomfortable with it. Of course, it is also enough like a loaded gun without a safety that you can easily get it to generate really stupid code without it warning you (move a byte register into a long? no problem. push a word register without specifying a size on the instruction? I hope you don't mind a 32-bit instruction, etc.). --Nyef

Consolemu Guest	The 68000 makes sense! Posted: Mon Apr 17, 2000 3:25 pm
Consolemu Guest	Now I see. It's not that the 68000 is the mighty backwards chip, but it's the other chips that are mighty and backwards! The 68000 is simple, straight-forward and powerful! I really like it's syntax. There's no mistake in what you're doing. If I want to move a byte, I type: `move.b` If I want to move a word, I do so like this: move.w And all the codes are in an english-like pattern. I haven't found anything backwards about it. Things make a lot more sense when their written in a pattern that I can read... `code value,register --------------------- move.w $4000,d0` My final question is does the 68000 store it's bytes in Little Endian or Big Indian? Like this, 76543210? Or this? 01234567. Cause, if it did it like this, 01234567, in a normal, readable way, I'm going to shout! Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Wait a minute... Posted: Mon Apr 17, 2000 3:32 pm
	Quote > For the record, some CPUs (the 6280 or the Z180 for example) actually do have bankswitching in the CPU. And you can view an MMU as a special case of a bankswitcher, which would mean that for all x86 where x >= 3 the CPU has a bankswitcher. In a sense, yes. Interesting processor notation, I'd just say '386's and above'. Quote > > PROGRESS. > > What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually). > I don't suppose you'd be willing to let that go real cheap? ^_^ Sure! I'll sell it to you for only $2000 -that's $500 less than I paid for it! Quote > Well, I'm taking a good long look at the possibility of switching lands. Say, a MISC chip? Okay. "A MISC chip?" Satisfied? Quote > I've been thinking that it should be either source, destination, mnemonic or destination, source, mnemonic, but I'm not sure which. ^_^ can't figure that logic. You must be canadian. Quote > Objection. 6502 ASM only ever uses one operand. You never see source and destination in the same instruction, so the relative order doesn't come into play. Yes it does, when the source and destination are coded into the mnemonic: Does TAX transfer X to the accumulator? No, it transfers the accumulator to X. The occurances are rare, but it was enough to set a precident. Quote > And I agree about the trailing h notation. To represent a number beginning with a digit greater than 9, you have to prefix it with a 0. It's also harder to write a parser for. I can think in hex, but not martian. Quote > > GNU C/DJGPP's assembly syntax is enough like Motorola Syntax that I don't feel so uncomfortable with it. > Of course, it is also enough like a loaded gun without a safety that you can easily get it to generate really stupid code without it warning you (move a byte register into a long? no problem. push a word register without specifying a size on the instruction? I hope you don't mind a 32-bit instruction, etc.). I always specified size in the instruction (I picked up that habit in the 68000 days, at the advice of my assembly book). So I haven't had many problems.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: The 68000 makes sense! Posted: Mon Apr 17, 2000 3:37 pm
	Quote > Now I see. It's not that the 68000 is the mighty backwards chip, but it's the other chips that are mighty and backwards! The 68000 is simple, straight-forward and powerful! I really like it's syntax. There's no mistake in what you're doing. If I want to move a byte, I type: > `> move.b >` > If I want to move a word, I do so like this: > move.w > And all the codes are in an english-like pattern. I haven't found anything backwards about it. Things make a lot more sense when their written in a pattern that I can read... I do like the syntax. Of course, theorerically, you could use motorola syntax in a PC assembler, or Intel syntax ina 68000 assembler. In fact, I think there was a motorola syntax assembler for the x86, though I believe it only supported real mode. You'll also find that it's syntax for using register offsets is much more readable that intel's. Quote > `> code value,register > --------------------- > move.w $4000,d0 >` > My final question is does the 68000 store it's bytes in Little Endian or Big Indian? Like this, 76543210? Or this? 01234567. Cause, if it did it like this, 01234567, in a normal, readable way, I'm going to shout! It's big endian, knock yourself out. I happen to see that there are pros and cons in each word format, but I still prefer big endian, just because that's why I got used to first.

Nyef Guest	Re: Wait a minute... Posted: Mon Apr 17, 2000 5:25 pm
Nyef Guest	Quote > Interesting processor notation, I'd just say '386's and above'. Yes, you probably would. :-P Quote > > > PROGRESS. > > > What's wrong with that? a 24bit addressable space was enough for the time, but later hardware that needed 68000 compatiblity also needed more addressing space. Thus, my 68040 Amiga 4000 has 18 megs of ram in it, but still runs 68000 based amiga software (usually). > > I don't suppose you'd be willing to let that go real cheap? ^_^ > Sure! I'll sell it to you for only $2000 -that's $500 less than I paid for it! Not exactly my definition of "real cheap". I think I'll wait for the new amiga or something. Quote > > I've been thinking that it should be either source, destination, mnemonic or destination, source, mnemonic, but I'm not sure which. ^_^ > can't figure that logic. You must be canadian. I can't follow your logic there. Ah, well. I'll just finish writing this assembler and then inflict the notation on all the normal, right-thinking people around here. ^_^ And no, I'm not canadian. Quote > > Objection. 6502 ASM only ever uses one operand. You never see source and destination in the same instruction, so the relative order doesn't come into play. > Yes it does, when the source and destination are coded into the mnemonic: Does TAX transfer X to the accumulator? No, it transfers the accumulator to X. > The occurances are rare, but it was enough to set a precident. No, those are implied addressing mode instructions, so they don't really have operands. If it were "A X LD," or "mov a, x" you might have a case, but it isn't, so you don't. Quote > I can think in hex, but not martian. That would have been funnier if you had said "I grok hex, but not martian". Exactly why is left as an excersize for the reader. ^_^ Quote > > Of course, it is also enough like a loaded gun without a safety that you can easily get it to generate really stupid code without it warning you (move a byte register into a long? no problem. push a word register without specifying a size on the instruction? I hope you don't mind a 32-bit instruction, etc.). > I always specified size in the instruction (I picked up that habit in the 68000 days, at the advice of my assembly book). So I haven't had many problems. Well, I started specifying sizr in the instruction after I realized that GNU as had no protection at all. I'm not saying I have had problems, just that it's annoying. --Nyef

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Wait a minute... Posted: Mon Apr 17, 2000 10:55 pm
	Quote > > > I don't suppose you'd be willing to let that go real cheap? ^_^ > > Sure! I'll sell it to you for only $2000 -that's $500 less than I paid for it! > Not exactly my definition of "real cheap". I think I'll wait for the new amiga or something. (hah). Cheap bastard, I was going to throw in an emplant board for free, too. Quote > I can't follow your logic there. Ah, well. I'll just finish writing this assembler and then inflict the notation on all the normal, right-thinking people around here. ^_^ japanese speakers will probably like it. Quote > And no, I'm not canadian. i don't know about that. Quote > > Yes it does, when the source and destination are coded into the mnemonic: Does TAX transfer X to the accumulator? No, it transfers the accumulator to X. > > The occurances are rare, but it was enough to set a precident. > No, those are implied addressing mode instructions, so they don't really have operands. If it were "A X LD," or "mov a, x" you might have a case, but it isn't, so you don't. Yes I do. The choice to roll the operands into the mneumonic was completely arbitrary. Zilog could just have well called ld b,c something like 'tcb'.. it is a one byte instruction after all. The 'tax' instructions has two operands, and they're not 'implied' but clearly specified in the mnemonic. Quote > That would have been funnier if you had said "I grok hex, but not martian". Exactly why is left as an excersize for the reader. ^_^ Naw, the whole 'grok' business is overused. Though I suppose with the whole martian thing... hell with it. Quote > Well, I started specifying sizr in the instruction after I realized that GNU as had no protection at all. I'm not saying I have had problems, just that it's annoying. It made a man out of you.

Nyef Guest	Re: Wait a minute... Posted: Tue Apr 18, 2000 5:00 pm
Nyef Guest	Quote > > I can't follow your logic there. Ah, well. I'll just finish writing this assembler and then inflict the notation on all the normal, right-thinking people around here. ^_^ > japanese speakers will probably like it. Cool! Now I'll definately inflict it on the people here. ^_^ Quote > Yes I do. The choice to roll the operands into the mneumonic was completely arbitrary. Zilog could just have well called ld b,c something like 'tcb'.. it is a one byte instruction after all. No, if it's arbitrary it implies that there isn't a tradeoff involved, and with the Z80 there is a definate tradeoff between assembler parser complexity and the number of mnemonics required for the 8-bit load group. Quote > The 'tax' instructions has two operands, and they're not 'implied' but clearly specified in the mnemonic. If they are specified in the mnemonic, they are impied. They could have easily called it something silly like LSR (Load Stack Register, see also the LMSW instruction on the x86, later "move cr0, reg" (stupid "destination, source notation")), or do the Z80 thing and have something like "LD R, A", even though that's the only way to set the R register on the Z80. Quote > > Well, I started specifying sizr in the instruction after I realized that GNU as had no protection at all. I'm not saying I have had problems, just that it's annoying. > It made a man out of you. No, that was done by using packed structures in gcc to hold x86 machine code to do stuff when a return statement is executed in the middle of a procedure (and yes, this was implemented by rewriting the return address on the stack). Then there were the times I used packed structs of machine code and memcpy() to create procedures at runtime... Scared yet? ^_^ --Nyef

Consolemu Guest	Ahhhhh!!! Posted: Tue Apr 18, 2000 9:48 pm
Consolemu Guest	Ahhhhh!!!!! Yeah!!! Sweet!!! Chris :o)!!!

Forums

View topic - Segments: Offsets...Again