Recent

Author Topic: IRC channel  (Read 6490 times)

Bogen85

  • Sr. Member
  • ****
  • Posts: 379
Re: IRC channel
« Reply #60 on: December 02, 2022, 01:32:04 pm »
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?

Even for x86_64 and i686 (well, all 32 bit and 64 bit  AMD/Intel) there are multiple variants.
AT&T syntax, used by GCC.
Intel syntax.
Nasm.
Fasm.
Yasm.
And likely variants used by MSVC (Microsoft's C compiler), and also others I'm not aware of.
Though for those variants the syntax is mostly the same.

But that is just for AMD/Intel 32/64 processors commonly used on laptops/desktops/servers.

ARM processors are completely different instruction sets, and you have 32/64 bit variants with them, so different assembly language.
MIPS 32/64, different as well.
PowerPC 32/64, different as well.

Of course that is just the tip of the iceberg as far as all the instruction sets in common use.

There is no way you can have a standard assembly language across different instructions sets.
While the syntax may be similar, the mnemonics and operands are specific to the instruction set.

FPC targets aarch64, arm, avr, i386, i8086, jvm, m68k, mips, mipsel, powerpc, powerpc64, sparc, x86_64 (and others), and while there may some overlap between closely related architectures, those are all going to different assembly languages.
« Last Edit: December 02, 2022, 02:05:30 pm by Bogen85 »

alpine

  • Hero Member
  • *****
  • Posts: 633
Re: IRC channel
« Reply #61 on: December 02, 2022, 02:25:15 pm »
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?

As the others commented out, it is not standardized in any way and, you may assume that the different processors have also different instruction sets.

But IMO it is not what matters most, what matters is the actual knowledge of how the processor works in general - aka the architecture (of which the instruction set is an integral part  ::) )

For example, my explanation in reply #51 is valid for so called "Princeton architecture" and not so much for some exemplars of the "Harvard architecture". Since the former very much prevails over the latter, it actually isn't worth it pursuing alternative explanations.

Learning assembly language nowadays can be justified only by a purpose to gain enough understanding of the architectural principles, especially from the people intending to use high-level languages as Pascal. Coding in assembly should be considered only in extreme cases, by compiler experts or people who wants to squeeze the last tiny bits of performance (often it is more reasonable to revise your algorithm than to resort to assembly for the latter).

What I think is that maybe instead of learning assembly, a wiki article will be of great help for a novice. An article explaining the calling mechanisms, stack, heap, managed types, etc. Most of the members here are experts and tend to neglect such an (obvious) things at the expense of others, more trendy.

"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

Kays

  • Sr. Member
  • ****
  • Posts: 479
  • Whasup!?
    • KaiBurghardt.de
Re: IRC channel
« Reply #62 on: December 02, 2022, 02:37:09 pm »
I have been following the discussion a while. I wonder, is this the lRC channel? Yohoo! Hellooohoohoo, I’m on lRC! 58008. Interdimensional Rogue Community rulez!
Yours Sincerely
Kai Burghardt

Aruna

  • Full Member
  • ***
  • Posts: 113
Re: IRC channel
« Reply #63 on: December 02, 2022, 02:39:38 pm »
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?

That is best answered by asking this question first. Does assembly language depend on the CPU?

Assembly language (or Assembler) is a compiled, low-level computer language. It is processor-dependent since it basically translates
the Assembler's mnemonics directly into the commands a particular CPU understands, on a one-to-one basis. These Assembler mnemonics are the instruction set for that processor.

Assembly languages cannot be standardized because each type of computer has a different instruction set and, therefore, a different assembly language.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8620
  • Debugger - SynEdit - and more
    • wiki
Re: IRC channel
« Reply #64 on: December 02, 2022, 02:56:38 pm »
I wouldn't go to deep into assembler.  Each CPU type has there own.
- Intel/AMD
- Apple M1
- various arm...
....

For the stack, you need:

call / ret
which is the kinda origin.
call will push the return address, ret will pop it.

And you want to know what a "stack frame" is.


One step back, and without asm.

Look at the heap - your "unorganized" ram.
It's just a continuous memory, like a set of boxes you can store stuff in.

And the problem is fragmentation:
- you allocate 3 times 10 boxes
- you no longer need the middle block of 10 boxes, you free it, now you have a gap
You can use that gap for anything up to 10 blocks. But not for 11 blocks.

In consequence, if you allocated all your memory in chunks of 10 blocks, and you freed every second such block, then you have thousands of free blocks, yet you can't allocate a consecutive block of 11.

And, if you deal with heap, the mem-manager must keep track of all those blocks.



A stack is continuous.
It is allocated up to a certain address.

If you need to push on it (or generic allocate space), you take that space at the very top (the side with the "certain address") of the stack (no gaps introduced).
If you need a further block, you allocate it again in the same manner.
=> Now you simply can't free the first block before you freed the 2nd.

Example (here I will allocate by increasing / on Intel the stack works downwards, but that doesn't change the concept):
- Your stack start at $0100000
- Your stack pointer (the marker up to were it is allocated) is at the same address $0100000 => the stack is empty
- You allocate $10 bytes, your stack pointer goes to $0100010 ($10 diff to the "stack start")
- You allocate another  $20 bytes, your stack pointer goes to $0100030 ($10 + $20 diff to the "stack start")

Now you can see, you can't free the first $10 bytes, unless you freed the $20 too. Because you can't decrease the stackpointer to $0100000 without freeing the $20 too.
And if you decreased it by $10 from $0100030 to $0100020 you would free half of the $20 instead of the $10 block.

And that is the concept. It makes management easier.


Now as I said, one big use is the return address.

There is also pop/push to add/remove. (obviously the last pushed must be popped first FIFO)

***
And there are stack frames.

if you enter a procedure that has locals, it may need $80 bytes for the locals (all fixed size).

Lets say the stackpointer was at $0100500
- The procedure takes the current $0100500 and stores it as frame base.
- it allocates $80 bytes => stack pointer to $0100580
  Remember those can only be freed if all subsequent allocs have been freed too.
  Nested/called procedures may alloc stack => but will also free it when the return
  And when this function will return, it will be able to free its chunk.
- And this block of memory is now this functions stack frame. The function remembers the address $0100500 independent of the stackpointer (on Inter CPU there is a register for that RSP stack-base / but it's not mandatory to use)

Obviously a dynamic array can't go into this stackframe, because the size of the frame is constant. If you have a local dyn array that is ok, because it is just the pointer. And the data goes on the heap.

Records are fixed size, and can go on the stack-frame

"objects" (instance of class") are NOT fixed size. They could be of an inherited class with more fields. So therefore they are a pointer, and must go on the heap.

"objects" old style are fixed size. And with inheritance that is trouble / and an entire topic of it's own / and a "just keep away from it..."



And thats it.

You avoid fragmentation and managing fragments....

Now you can decide, if you still need asm.


On Intel stacks increase downwards.

So if it starts an $0100000 and you alloc $10 the pointer goes to $00FFFF0 (and your allocated me is from $00FFFF0 to $0100000  / doesn't matter, unless you do asm, or otherwise hack into the stack)







Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8620
  • Debugger - SynEdit - and more
    • wiki
Re: IRC channel
« Reply #65 on: December 02, 2022, 03:04:27 pm »
In terms of "where is a variable" / how code accesses it.

** If you have a global var "int64"
Allocated at compile time.

During compilation the compiler will allocate a fixed address (in the data segment, which is a pre-allocated part of the heap)
Accessing the var, just generates code
 "load data from fixed address xxxx"

** If you have a local var "int64"
During compilation the compiler will allocate an address by fixed offset in the stack frame.
E.g. 2nd var in the frame may be at framebase+8

Accessing the var, just generates code
 "load data from value-in-frame-base-register + offset xxxx"

** Field in an instance on the heap
This object (of class) can be a global or local.
The object is the address.

In case of a local, the compiler will allocate the space for the address at an offset on the stack base
Accessing then is 2 steps
 "load ADDRESS from value-in-frame-base-register + offset xxxx"
 "load data from ADDRESS + offset for field"





440bx

  • Hero Member
  • *****
  • Posts: 3268
Re: IRC channel
« Reply #66 on: December 02, 2022, 03:19:58 pm »
As a number of members have already either mentioned or implied, the purpose of learning Assembler (for a particular CPU) isn't to write entire programs in Assembler.

The main reasons to learn assembly these days, is to _understand_ how a CPU works and to have precise control over it whenever it is needed.  There are times when compilers, even C/C++, do not provide the necessary facilities to exert the necessary control, in those cases Assembly is the solution.

While assembly language is not standardized, CPUs share quite a few characteristics and once you understand how one of them works, most of the concepts carry to others.  The implementation details (which are hardwired in the chip) will usually change but the concepts are readily identifiable.

I believe that if an intermediate level programmer spends a couple of weeks learning the basics of Assembly language programming, that will give him/her a significantly better understanding of how compilers and O/Ss work.    Of course, with just a couple of weeks, you barely knocked on the door but, it's enough to gain basic knowledge about very important concepts.

If you're inclined to learn more, once you've acquired some basic Assembly language skills, read the manufacturer's CPU documentation.  Intel and AMD have published extensive documentation about their processors that ranges from the basics to what you need to know to write a fully capable O/S for them.  Be forewarned, that documentation is more often than not dry as a bone (IOW, definitely not tutorials.) That said, it is quite readable.

Lastly, without getting your hands dirty, you can ask lots and lots of questions but, seeing how all the answers come together to make a coherent whole requires some practice in Assembly.

My recommendation is: do spend a week or two learning the basics of Assembly.  You'll be glad you did.

HTH.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 SP1 64bit.

Seenkao

  • Sr. Member
  • ****
  • Posts: 431
    • New ZenGL.
Re: IRC channel
« Reply #67 on: December 02, 2022, 03:33:21 pm »
Coding in assembly should be considered only in extreme cases, by compiler experts or people who wants to squeeze the last tiny bits of performance (often it is more reasonable to revise your algorithm than to resort to assembly for the latter).
По большей части я с вами согласен. Но, когда я делал функцию StrToInt на Паскале - компилятор FPC не полностью её оптимизировал. И когда я делал функцию StrToInt на ассемблере, то я получил намного более оптимизированный код. На Паскале, в данное время, мы не сможем получить подобный код. Я бы наверно сказал даже точнее, ни когда не сможем, если только в ассемблере не появятся какие-то новые функции.

Поэтому это всё зависит от кода, с которым мы работаем. Какой-то код FPC (Delphi, C/C++) сможет достаточно оптимизировать, а какой-то не сможет, как ни старайся. Но программируя только на FPC (Delphi, C/C++), мы этого не сможем  узнать.

Google translate:
For the most part, I agree with you. But, when I made the StrToInt function in Pascal, the FPC compiler did not fully optimize it. And when I made the StrToInt function in assembler, I got a much more optimized code. In Pascal, at this time, we will not be able to get such a code. I would probably say even more precisely, we will never be able to, unless some new functions appear in the assembler.

So it all depends on the code we're working with. Some FPC code (Delphi, C / C ++) will be able to optimize enough, and some will not be able to, no matter how hard you try. But using only FPC (Delphi, C/C++), we won't be able to find out.

I wouldn't go to deep into assembler.
Думаю, выбор должен сделать сам программист.  :)

Eng:
I think the choice should be made by the programmer himself.  :)
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.
Работаю над ZenGL.
Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL. :)

lainz

  • Hero Member
  • *****
  • Posts: 4073
Re: IRC channel
« Reply #68 on: December 02, 2022, 11:07:03 pm »
I like how posts are not following the "IRC channel" theme. Including myself.
lainz.github.io

KodeZwerg

  • Hero Member
  • *****
  • Posts: 927
  • Fifty shades of code.
    • Delphi & FreePascal
Re: IRC channel
« Reply #69 on: December 02, 2022, 11:22:16 pm »
I like how posts are not following the "IRC channel" theme. Including myself.
Moderator also  >:D O:-)

From complain about that a person take over a thread, small discord vs irc and look where we are now, assembler yay, again take over with one thing after another, @GetMem :-[
« Last Edit: Tomorrow at 31:76:97 by KodeZwerg »

Bogen85

  • Sr. Member
  • ****
  • Posts: 379
Re: IRC channel
« Reply #70 on: December 03, 2022, 12:22:48 am »
I like how posts are not following the "IRC channel" theme. Including myself.

Well, this topic largely arose because of someone's desire to use IRC to get FPC/Lazarus help because it is free form and unstructured, and does not need to be formal like the forums.

So this topic thread is being treated as such. A desire to get help, but little desire to follow a structure, and the expectation that others will accommodate.

However, to be most useful forum threads really need to be on topic so that others can do web searches on particular issues and find them in related forum Topic threads.

Others want the forum to be useful. Not only for others to get help, but also as a place to refer back to for questions they may have asked or participated in, so they can search the forums to recall what they had seen before.

IRC lacks all this structure. So even though help can be obtained in an IRC like medium, it is not really useful to refer to back to.

So a lot has to repeated again and again. So for many, they want to stick to forums, as they find IRC to in general not be good time management.

I find the forums far more useful to get help. I can and do bookmark specific Forum posts and replies to refer back to later. So I don't have to keep asking others in chat for information I already had obtained.

In looking for help in the forums I've found answers dating back 10+ years.

Even if I had 10 years worth of IRC logs, sifting and searching them would be verify difficult to find what I'm looking for. Forum posts and replies are expected to be organized in order to be the most usefu.

So this thread even though it has visited several subjects could  "on topic" in the sense it is trying convey the feeling of the conversations in an IRC channel...

Joanna

  • Full Member
  • ***
  • Posts: 227
Re: IRC channel
« Reply #71 on: December 04, 2022, 01:24:34 am »
I have been following the discussion a while. I wonder, is this the lRC channel? Yohoo! Hellooohoohoo, I’m on lRC! 58008. Interdimensional Rogue Community rulez!
That is a rather satirical commentary in irc. In reality it’s not quite so exciting. The majority of accounts in irc are lurkers who never talk. The experience of being in irc depends upon who is participating in the channel. IRC does have a lot of technical people as well as posers who don’t fare so well when asked technical questions. Some channels have trolls join them for the purpose of discrediting and discouraging usage of whatever the channel is about. There are also are professional influencers who come to irc to promote political agendas. I wish more people who do pascal programming would be active in irc.

 If you are curious about irc why not come try it out on Libera?

Quote
IRC lacks all this structure. So even though help can be obtained in an IRC like medium, it is not really useful to refer to back to.

Irc is a text version of talking or storytelling It’s supposed to be fun, informative and social . Who cares if the same things are talked about more than once? Repetition Is a normal phenomenon and can be good for learning things. It’s ok to bounce around to different pascal related topics in irc or even chat about off topic things sometimes.
I certainly wouldn’t mind chatting about assembly language in irc but the forum allows people in different time zones to participate and that is good as well.  :D

As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus? If I’m on different computer would that assembly language be different?  I don’t suppose that there is a way to make assembly language cross platform?

Quote
when I made the StrToInt function in Pascal, the FPC compiler did not fully optimize it. And when I made the StrToInt function in assembler, I got a much more optimized code. In Pascal, at this time, we will not be able to get such a code.
Is there a way to improve the fpc compiler to be as fast for that as assembly language maybe?

Also regarding the problem mentioned about the memory becoming fragmented at runtime how is the memory manager implemented to defragment the heap? Does it slow things down a lot when used?
« Last Edit: December 04, 2022, 02:50:38 am by Joanna »
Come chat on IRC .. https://libera.chat/guides/
IRC.LIBERA.CHAT  Ports [6667 plaintext ] or [6697 secure] channels  #fpc #lazarus #pascal 
type /msg nickserv help register to get started

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8620
  • Debugger - SynEdit - and more
    • wiki
Re: IRC channel
« Reply #72 on: December 04, 2022, 03:11:09 am »
As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus? If I’m on different computer would that assembly language be different?  I don’t suppose that there is a way to make assembly language cross platform?

Each CPU (type) has it's own assembly language (well, see below)

AMD and INTEL desktop CPU share the same.
Apple M1 is different.
ARM / AVR are different
....


Assembly is the human representation of the "machine code" that is executed by the cpu.
So each CPU (type) has a set of machine code.

The human representation can vary.

For example for the Intel/AMD code there are actually 2 common representations.
They both have the same set of commands, but different names, different symbols for the same thing.

Google: intel vs at&t syntax

440bx

  • Hero Member
  • *****
  • Posts: 3268
Re: IRC channel
« Reply #73 on: December 04, 2022, 04:01:27 am »
Irc is a text version of talking or storytelling It’s supposed to be fun, informative and social .
real time "chatty" mediums have those characteristics but, for topics that are often centered on problem solving, a static thread of text messages (such as this forum) is usually a much better medium because the progression to the "solution" or best answer isn't simply lost.  Here anyone can go back to the beginning or any other message of interest and see the progression towards the current state.   For anything that is inherently technical, that is a very desirable characteristic.

As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus?
Yes but, as @Martin_fr pointed out, the syntax may differ.

If I’m on different computer would that assembly language be different?
Yes, it would because the instructions implemented by two different processors will usually differ and sometimes the differences are _very_ large.

I don’t suppose that there is a way to make assembly language cross platform?
True assembly language ? ... the answer is NO.    That said, C is generally considered a "high level assembler" and it is very portable but C, unlike assembly, does _not_  give the programmer the ability to choose which registers are going to be used to implement an instruction or series of instructions.

Also regarding the problem mentioned about the memory becoming fragmented at runtime how is the memory manager implemented to defragment the heap? Does it slow things down a lot when used?
The slowdown will depend on the level of fragmentation and greatly depend on the algorithms used to manage it.

The best way of managing fragmentation is to _avoid_ it.  Once fragmentation is significant enough to be a concern, it will already be a PITA.

Avoiding fragmentation means, do your own memory management (which is not hard to do at all - if you've learned how to do it, it's like riding a bicycle, you won't even need to use your hands.)

HTH.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 SP1 64bit.

Bogen85

  • Sr. Member
  • ****
  • Posts: 379
Re: IRC channel
« Reply #74 on: December 04, 2022, 04:12:36 am »
As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus? If I’m on different computer would that assembly language be different?  I don’t suppose that there is a way to make assembly language cross platform?

If on a different processor architecture it would be different.

No, it can't be made cross platform. That would be impossible.

See https://godbolt.org/

They only have one architecture there for Pascal (X86-64).

So on the left select Ada, as that example is the closest to Pascal.

And on the right select the architecture (ARM, ARM64, MIPS, MIPS64, POWER, POWER64, POWER64LE, RISCV64, S390X, SPARC, SPARC64, X86-64)

Instruction set architectures are designed by different companies and individuals. There is no standard that architectures must follow as far as the resulting assembly languages.

While there might be some similarities, there is no way to represent all of them in a common format.
They have different instructions, modes, registers, status bits, etc. (some are stack based and not purely register based, and other differences).

Any attempt to make a cross platform output in some common format would make it very difficult for anyone familiar a particular architecture because the designers of that architecture unlikely have published anything for their instruction set according to some common standard, especially when said common standard does not exist.

For more differences between architectures see: https://en.wikipedia.org/wiki/Comparison_of_instruction_set_architectures
« Last Edit: December 04, 2022, 04:21:18 am by Bogen85 »

 

TinyPortal © 2005-2018