Need to know parameter format for a Call function?

[laserlight]

How in the name of Odin is this better than SQL? ISO Standard SQL defines a common interface that many engines implement, with varying degrees of adherence. If you know SQL, you can store and retrieve data from any number of SQL implementations. You don't need to know assembly language. You don't need to know a proprietary API. In every implementation that I've seen, you don't even need to write a program to use SQL.

I think that this is answered in post #28:

What I would like to do is replace the code in SQL that accesses the data device with ADAM.

That is, Will1 is going for your suggestion that ADAM provide a storage engine for higher level database systems. This arguably fits even the claim from the MASM32 forum that "if you need something to create a data base system, it's the best there is", i.e., if you need that component to implement a higher level database system, then Will1 asserts that this is the best available. The problem with this interpretation is that Will1 has also made claims that compare ADAM with SQL and relational database systems and -- if we infer from the comment about cloud computing -- other high level approaches to database systems.

Will1: could you clarify this?

[phantomotap]

If you change your mind, a write up of your algorithms and data structures would receive a lot more peer review than releasing just the source code alone.

O_o

Are you part of that discussion? Or do you just have mad ranks in "googlefu"?

[Edit]
How has no one referenced "Berkeley DB" or any of the other bazillion key/value or similarly many "big block" stores?
[/Edit]

Soma

[laserlight]

How has no one referenced "Berkeley DB" or any of the other bazillion key/value or similarly many "big block" stores?

Because this doesn't seem to be along the same lines, or rather claims to be along the same lines and more, and then maybe not. The closest we get to the interface provided by ADAM for database functionality is from post #37, which does remind me of those, but then we have claims like "SQL does have the ability to establish relationships but it is cumbersome and could be done more efficiently by a program".

[phantomotap]

Because this doesn't seem to be along the same lines, or rather claims to be along the same lines and more, and then maybe not.

O_o

My views could probably be inferred, but several of you are participating. That being your view only makes me wonder more why you haven't asked how this compares with such other systems. We've only really seen "buzzword bingo" or "I'm not telling." when directly asked so I was seriously wondering why other comparisons, other than SQL, haven't been invited.

then we have claims like "SQL does have the ability to establish relationships but it is cumbersome and could be done more efficiently by a program".

We've also seen "real", "best", "fastest", "easiest", and similar thrown around. I'm not sure "more" and "different" have any more a reliable meaning when faced with a salesmen.

Soma

[laserlight]

That being your view only makes me wonder more why you haven't asked how this compares with such other systems. We've only really seen "buzzword bingo" or "I'm not telling." when directly asked so I was seriously wondering why other comparisons, other than SQL, haven't been invited.

Patience, my old padawan.

[stahta01]

I think we need some specs of this database.

Max number of rows?
Max size of a single column in a row?
Max number of columns in a table?
Max number of table joins?
Are left joins supported?
Is something like SQL null supported?

Tim S.

[Will1]

I think we need some specs of this database.

Max number of rows?
Max size of a single column in a row?
Max number of columns in a table?
Max number of table joins?
Are left joins supported?
Is something like SQL null supported?

Tim S.

Those are all SQL functions. If you were to use ADAM you would need to think in records and fields rather than rows and columns. In any event, It looks like I'm just going to have to abandon the project. Even IBM's OS/2 operating system restricted program's from using the DS and ES registers. I can only tell you that, when the 186 was the state of the art processor, I wrote an application for Snelling and Snelling for their "temp" data base that had blink of an eye speed running under DOS. Nothing else would run with that kind of speed. It's too bad I don't have the facilities or the time to write a really good Operating System, and DOS is, size wise, so small that it has been out-dated. The other thing that has happened is that the modern processors are so fast that you can write terribly inefficient code and it will run reasonably fast because of the speed of modern processors. Wonder why the dinosaur main frames that IBM deals in are still being used? I think our prsident found out when he tried to get too many people, too fast to sign up for Obamacare.

[stahta01]

Those are all SQL functions. If you were to use ADAM you would need to think in records and fields rather than rows and columns. In any event, It looks like I'm just going to have to abandon the project. Even IBM's OS/2 operating system restricted program's from using the DS and ES registers. I can only tell you that, when the 186 was the state of the art processor, I wrote an application for Snelling and Snelling for their "temp" data base that had blink of an eye speed running under DOS. Nothing else would run with that kind of speed. It's too bad I don't have the facilities or the time to write a really good Operating System, and DOS is, size wise, so small that it has been out-dated. The other thing that has happened is that the modern processors are so fast that you can write terribly inefficient code and it will run reasonably fast because of the speed of modern processors. Wonder why the dinosaur main frames that IBM deals in are still being used? I think our prsident found out when he tried to get too many people, too fast to sign up for Obamacare.

Wrong about those being SQL database items; they are all relational database items.
The only difference is they do NOT normally use the names rows and columns instead the word tuples is used often in relation algebra and relational database field.

Sounds like ADAM is NOT a relational database.

Tim S.

[Elkvis]

Even IBM's OS/2 operating system restricted program's from using the DS and ES registers.

And I've been trying to tell you throughout this discussion that you don't need them. I can guarantee beyond a shadow of a doubt that there is a way to implement your system without using segment registers. You said in an earlier post that protected mode isn't the problem. Based on your own description of ADAM, I'd say that it is. I say that simply because segments don't work the same way in protected mode as they do in "real address" mode, as in DOS. Memory addressing happens in a completely different way in protected mode, which I outlined briefly in post 24.

[Will1]

And I've been trying to tell you throughout this discussion that you don't need them. I can guarantee beyond a shadow of a doubt that there is a way to implement your system without using segment registers. You said in an earlier post that protected mode isn't the problem. Based on your own description of ADAM, I'd say that it is. I say that simply because segments don't work the same way in protected mode as they do in "real address" mode, as in DOS. Memory addressing happens in a completely different way in protected mode, which I outlined briefly in post 24.

The CS, DS, and ES registers act as "Base" registers. A (mainframe) Base register is a register that you use as a Base and offset the Code and Data from the address held in the Base register. I'll guarantee you that Windows and Liinux use the (E)CS, E(BS) and E(ES) registers as Base Registers. Programming without being able to establish Base Registers makes it virtually impossible to do complex passing of data between programs (and subroutines) that are compiled separately. It virtually destroys the ability to write really good subroutines like ADAM. Tell me how you pass the address of a "record" (column) of data between a program and call a separately compiled subrotine that uses it. (I managed to do that for 1 ADAM file by "cheating Windows" but most uses of ADAM, like SQL, require more than 1 file (data structure). For KISS puposes if I move field A to field B, A must be at an offset from a Base register and B must be at an offet from a Base register, otherwise how could my program address them?

Using tables instead of Base registers seems terribly inefficient to me!

[Elkvis]

Programming without being able to establish Base Registers makes it virtually impossible to do complex passing of data between programs (and subroutines) that are compiled separately.

Most non-embedded database systems use shared memory, named pipes, or other IPC (inter-process communication) systems to communicate between application and database. They each have their own isolated memory space, and the OS kernel facilitates the communication.

It virtually destroys the ability to write really good subroutines like ADAM.

Considering that you still have yet to show any side-by-side comparisons with systems with which forum members might be familiar, making this claim is difficult to justify.

Using tables instead of Base registers seems terribly inefficient to me!

The "efficiency" you lose is offset by the fact that you can access all the memory that the processor can physically address. In order for segmentffset to work the same way as it does in DOS, segment registers would need to be 32/64 bits wide, and would likely bloat applications far beyond reasonable limits.

The important thing that you need to remember is that the processor handles the tables at a very low level. If your program had to maintain and enforce them, it would be incredibly inefficient, as you say, but the processor does it automatically with ease. Memory protection (responsible for your inability to use the segment registers in the way you want) is very important for security.

[laserlight]

If you were to use ADAM you would need to think in records and fields rather than rows and columns.

It makes no difference since you do not explain what "records" and "fields" are in the context of ADAM. That which we call a rose by any other name would smell as sweet. If you have a very different paradigm for data storage, then you have not given any hints of it, other than in post #37, which does not provide any such explanation.

I can only tell you that, when the 186 was the state of the art processor, I wrote an application for Snelling and Snelling for their "temp" data base that had blink of an eye speed running under DOS. Nothing else would run with that kind of speed.

There are current non-relational database systems that do not use SQL and which can be used when one needs a '"temp" data base', among other things, and that are usually sufficiently blazingly fast for this purpose. Then there are relational database systems that do use SQL and which can also be used when one needs a '"temp" data base', e.g., SQLite can be embedded into a C program to utilise an in-memory database.

phantomotap was so excited over in post #49 asking 'How has no one referenced "Berkeley DB" or any of the other bazillion key/value or similarly many "big block" stores?' Did you read that? Tokyo Cabinet is another well known example, though I see that it has been superseded by Kyoto Cabinet. (Off-topic: for the actual cities, I prefer Kyoto to Tokyo, so that is good news for me )

It's too bad I don't have the facilities or the time to write a really good Operating System, and DOS is, size wise, so small that it has been out-dated.

"I have discovered a truly marvellous proof of this, which this margin is too narrow to contain."

Sounds like ADAM is NOT a relational database.

I note that Will1 has not responded to my post #48.

[phantomotap]

That which we call a rose by any other name would smell as sweet.

O_o

If it looks like a duck, swims like a duck, and performs a unit join by processing prepared statements sampling information from a store of a values like a duck, then it probably is a duck.

o_O

Wait. That doesn't sound at all correct...

Soma

[phantomotap]

I'll guarantee you that Windows and Liinux use the (E)CS, E(BS) and E(ES) registers as Base Registers.

O_o

You are correct in that most kernels still use those registers; you are just wrong in how those registers are used.

Tell me how you pass the address of a "record" (column) of data between a program and call a separately compiled subrotine that uses it.

LibraryRoutine(&MyRecord);

For KISS puposes if I move field A to field B, A must be at an offset from a Base register and B must be at an offet from a Base register, otherwise how could my program address them?

A universal offset is in every way superior to a segment offset for such a trivial mission.

Using tables instead of Base registers seems terribly inefficient to me!

Are you seriously not aware that professional database engines push metal?

Programming without being able to establish Base Registers makes it virtually impossible to do complex passing of data between programs (and subroutines) that are compiled separately.

This is so extraordinarily wrong I am now confident that you are putting significant effort into being wrong.

Soma

[Elkvis]

What you fail to realize is that modern "mainframes" are really nothing more than high-end PCs with many CPU cores and tons of memory and mass storage. IBM's mainframes typically run Linux or AIX (IBM's flavor of UNIX), and bear little resemblance to the mainframes you knew 40 years ago. Chances are, they can still run the same software, in emulation layers, but for the price of a mainframe and a bunch of terminals that do nothing more than access the applications on the mainframe itself, you can get a somewhat lower spec server (or several) and the equivalent number of PCs, and still get the same performance or better, and get much greater user productivity, because the PC on the user's desk can do much more than simply access a mainframe and a rigid set of applications. The PC would run client applications for accessing server functions, and all the processing is still done by the server. The advantage is that now the user can access his/her company email, documents, and the web from the PC, without requiring any involvement from the server. This reduces the workload on the server, and frees up its resources for processing user requests.