old x86 assembly code but apparently wrong comment and synta

[ITchimp]

I was reading minix driver code for tty. What puzzles me is that
one of the assembly files like like the following... what question is that
although the assembly looks like intel syntax... but the comment format is
totally wrong and the .define is not a valid syntax format either...

what kind of assembly is that? is gcc supposed to handle this? Could this be a
very very old assembly syntax that has become obsolete?

Code: Select all

# 
! This file contains two specialized assembly code routines to update the 
! video memory. The routines can copy from user to video memory, or from
! video to video memory.   

! sections

.sect .text; .sect .rom; .sect .data; .sect .bss

! exported functions

.define	_mem_vid_copy	! copy data to video ram
.define	_vid_vid_copy	! move data in video ram

! The routines only guarantee to preserve the registers the C compiler
! expects to be preserved (ebx, esi, edi, ebp, esp, segment registers, and
! direction bit in the flags).

.sect .text
!*===========================================================================*
!*				mem_vid_copy				     *
!*===========================================================================*
! PUBLIC void mem_vid_copy(u16 *src, unsigned dst, unsigned count);
!
! Copy count characters from kernel memory to video memory.  Src is an ordinary
! pointer to a word, but dst and count are character (word) based video offset
! and count.  If src is null then screen memory is blanked by filling it with
! blank_color.

_mem_vid_copy:
	push	ebp
	mov	ebp, esp
	push	esi
	push	edi
	push	

[iansjack]

It's the syntax used by IBM's PC/IX assembler.

http://minix1.woodhull.com/pub/info/pc-ix-assem.txt

[Love4Boobies]

The MINIX documentation covers this and it was the first result that came up on Google. Finding yourself in a situation where you can't find the first result of a search query or think to look it up where it's supposed to be documented isn't a good sign as far as building self-reliance skills goes, is it? Calling it "wrong" is also kind of weird. It's like seeing Python when you're only familiar with C and complaining it's wrong.

I know it sounds like I'm being a bit of a **** but I think the point I am trying to make is a valid and potentially helpful one. Engineering is maybe more than half about learning self-reliance. The rest is problem solving and tricks of the trade.

[ITchimp]

I don't mean to be an @$$... but I want to find the shortest path forward where ever possible, I don't have 1000 years to live... so point me the shortest way forward and I will salute you!!!

how the **** do I compile this ? can I use gcc... do I have to manually translate to intel format???


help !!!!

[Combuster]

Based on the number of censorings, I should probably remind you that patience is quite a virtue. You can try if you can get hold of the original toolchain, but that means you will have the reverse problems when you come across code from people that are using more modern equipment. If you already have an established codebase, then what reason do you have to switch to that just for one piece of code?

And considering it's been one hour since you asked, I should be allowed to assume that you have at least tried running that assembly through gcc and figured out that part of the question already. After all if you are in such a hurry, why make us the holdup for your project?

[Love4Boobies]

But the way I am proposing is indeed the fastest way forward. Otherwise, you will get stuck at every step of the way, which isn't exactly going forward. It always seems like if you could just get past this one little hurdle, it will be smooth sailing from there. What you'll really be doing is to constantly spend time hoping to find a savior (this takes time) and a lot of the time there won't even be one because the problem will be too complex for them to invest time in without compensation. We've seen quite a bit of that over the years here, there are no exceptions.

I mean if it's the fastest way forward, why did it take me 10 seconds to find the answer when you're still unsure of it after several hours?

PS: Intel assembly syntax is actually a family of syntaxes. No current assembler really supports the original Intel syntax (and here is the manual before RadiSys aquired ASM386 alongside other things) anymore. GNU as has one form of Intel syntax, MASM has another, TASM has another, NASM has another, etc. Assembly language is not standardized so each assembler pretty much uses its own flavour, unless specifically designed to clone another assembler (e.g., YASM clones NASM, JWasm clones MASM, etc.).

[iansjack]

Poor Googling skills could excuse the original question, but the explanation that you didn't want to waste your time, but would rather others wasted their time on your behalf, really isn't acceptable.

If you want to play with Minix 1 then invest just a little of your time in the effort. When I first encountered Minix I typed the whole source code by hand, filling in missing parts and translating the code to suit my compiler/assembler. It took months. You don't have to make that effort as the source is now available on line.

[Schol-R-LEA]

I don't mean to be an @$$... but I want to find the shortest path forward where ever possible, I don't have 1000 years to live... so point me the shortest way forward and I will salute you!!!

That would be a web search, using Google, or DuckDuckGo, or Bing, or something similar, or even some combination of those with an aggregator such as Dogpile.

Asking on a forum, conversely, will always be the slowest way to get an answer.

Think about it: even on a chat channel (things like IRC, Discord, Slack groups, etc), you will often get no reply, or get a very delayed one. On fora like this one, or things like Stack Overflow, you may not get a response for days, if ever.

As others have already said - and as is repeatedly mentioned in the wiki which is on the same site as this forum, and in advice pieces such as famed "How to Ask Questions the Smart Way" - the first step is almost always to do a web search with Google or something similar - maybe even use several, as Bing and DuckDuckGo often get slightly different results from the Big G. The next is to search through available documentation, such as (in this case) the Minix home site and things like the OSDev wiki.

If you are going to go ask on a forum or IRC channel, use that forum's search tool first to see if someone has asked the question before. Asking on the forum itself is the last resort, the one you should do after everything else has come up empty, or if you need further clarification on any answers you did find.

Yes, it takes some skill to use search tools, and you may not get a correct answer. However, the same is true of asking questions effectively on fora like this one, and even if it fails, it fails a lot faster - you still can ask on the forum afterwards, and will at least be able to say that you tried all those other things first.

Also, the forum is the one least likely to return a useful answer - it may or may not be a more direct answer, but it could also get a blow-off answer, a trolling answer, or a merely misleading one. Sometimes the problem is the reader; other times, it is how you ask the question that matters.

For example, the earlier answer - that it was the PC/ix assembler syntax¹ - is only half an answer, as Minix 1.x didn't use the PC/ix assembler, it used the Amsterdam Compiler Kit toolchain's assembler, which used a slightly different dialect based on the PC/ix assembler.

Now, I am pretty sure iansjack didn't intend to mislead you; he found this right away, and it looked right, so he thought it would be the answer. He was right about the syntax, but the assembler that syntax came from wasn't the one actually used for Minix 1.

In sum: Use the available tools for the tings they are best suited to. In the case of a forum, it is best used for refining your information about something you already know, or getting opinions on things that don't have black and white answers. In other words, things that require thought and careful replies - replies which inevitably will take some time.

how the **** do I compile this ? can I use gcc... do I have to manually translate to intel format???

With the Amsterdam Compiler Kit toolchain assembler and C compiler, presumably.

Assuming you really do want to study the Minix 1.x code (which is a 30-year-old system for 8088 PCs, running in real mode), and not, say, move on to Minix 3.x, which uses the more familiar GNU toolchain and runs in 32-bit protected mode. I don't know if you have reasons to stick to the older version or not.

My guess is that you found an old copy of the Minix textbook in a library or used book store, or a copy of the Minix 1.x code online somewhere, and didn't realize how old it was. An easy mistake to make, to be sure.

Now, given that the current textbook (3rd edition, published 2006) costs a staggering US$181 new/US$52 used on Amazon US right now, I can't fault you if you don't want to spend that much. However, the current version of Minix is very different from the older version, and as I said, it uses the tools you probably were expecting to find, and the source code is actually more readily accessible than the older version, as it is under the BSD Open License (older versions are too, now, but initially it was proprietary) and can be downloaded in tot from the minix3.org website.

Actually, if you have git, about 100 MB of spare disk space, and ample download bandwidth, the easiest way to get the Minix 3.x is to clone the Git repo using the Git shell tools:

Code: Select all

git clone git://git.minix3.org/minix src

or just put the git://git.minix3.org/minix part into your Git client of choice. Instructions for cross-compiling it from Linux - or Windows, if you are using either Windows Subsystem for Linux (WSL) or Cygwin - can be found on this page of the Minix wiki.

Footnotes
1. Technically, it wasn't even the PC/ix syntax, originally.According to Wicked-Pedo, it came from a cross-assembler running whose name seems to be lost; the PC/ix version itself was a port of that, and as is usually the case, the ISC devs made some tweaks to the syntax along the way.

Developed in 1982 at MIT as a cross-assembler, it was picked up by Interactive Systems Corporation in 1983 when they developed PC/IX under IBM contract. The syntax was later used as base for ACK assembler, to be used in MINIX 1.x toolchain.

[sortie]

Schol-R-LEA just gave a really good and helpful response and sets a good example for this forum.

[Love4Boobies]

Schol-R-LEA ... sets a good example for this forum.

That's always quite subjective. I have him marked as a foe (together with ~) and can't see his replies.

(I don't mind if other people use that feature on me, it makes the forum much more pleasant.)

[iansjack]

I stand corrected.

The OP would never have discovered the comprehensive answer given by Schol-R-LEA by Googling. He would merely have found, as I did, the meaning of the syntax used in this assembler code.

Clearly it is better to ask questions here than to search online.

[Love4Boobies]

Whatever the answer was, I think that is missing the point. The idea is to get the OP to the point where they can formulate their own answers. They can never reach that level if they are spoonfed. Personally, I would simply use Tanenbaum's book that documents the source code. It covers the toolchain, as does the online documentation (where I found my answer).

[ITchimp]

Actually i have decided to port that odd looking assembly to gnu assembly... that seems like an easier route...


Thanks for your posting and help...

[Schol-R-LEA]

I just noticed something weird:

Code: Select all

_mem_vid_copy:
	push	ebp
	mov	ebp, esp
	push	esi
	push	edi
	push	

Now, I don't know where you got this code - it is from Minix 1.x or 2.x, but I have found it listed incorrectly as Minix 3.x in at least one place - but I can tell you that this shouldn't be possible. To the best of my knowledge, the ACK assembler (like the PC/ix assembler it was based on) was never re-written to support 32-bit registers - it was a real mode assembler, period. Using the E* registers (the 32-bit 'extended' version of AX, BX, SI, DI, and so forth) shouldn't be possible with that assembler.

If you changed it, trying to 'update' or fix it, well, that wouldn't be any use, it is real mode code and written in a way that wouldn't run quite right in 32-bit p-mode (even with the registers 'fixed') without what would amount to a total re-write.

OTOH, if the code was like this when you found it, I would say that is evidence of someone pulling a fast one on you.

The current version of Minix doesn't have anything like this as far as I can tell; the TTY drivers in the latest version are entirely in C, something which would have been difficult if not impossible on an XT class system from the 1980s but is readily possible on pretty much any system after 1992 or so.

[MichaelPetch]

Now, I don't know where you got this code - it is from Minix 1.x or 2.x, but I have found it listed incorrectly as Minix 3.x in at least one place - but I can tell you that this shouldn't be possible. To the best of my knowledge, the ACK assembler (like the PC/ix assembler it was based on) was never re-written to support 32-bit registers - it was a real mode assembler, period. Using the E* registers (the 32-bit 'extended' version of AX, BX, SI, DI, and so forth) shouldn't be possible with that assembler.

I happened to look through all the branches on Minix3.org for Minix3 and found that vidcopy.s still seemed to be used up through version 3.1.3. That seems to have changed in 3.1.4.